CVE-2024-6387: OpenSSH regreSSHion — Unauthenticated RCE in sshd

Background

OpenSSH is the de facto standard SSH implementation on Linux and Unix systems, present on virtually every Linux server globally. The SSH daemon (sshd) provides remote administration access, making it one of the most ubiquitous network-accessible services in existence. Any remotely exploitable vulnerability in OpenSSH is immediately significant due to the scale of deployment.

CVE-2024-6387, dubbed “regreSSHion” by Qualys researchers who discovered it, is a race condition vulnerability in sshd’s signal handling code. Disclosed in July 2024 with a CVSS score of 8.1, it allows unauthenticated attackers to achieve remote code execution as root on glibc-based Linux systems — the most severe possible impact for an SSH vulnerability. The name references that this is a regression: the same bug class (CVE-2006-5051) was fixed 18 years ago, but the fix was inadvertently reverted when OpenSSH 8.5p1 was released in 2021.

Technical Mechanism

CVE-2024-6387 is a signal handler race condition in sshd’s SIGALRM handler. Understanding the vulnerability requires understanding how sshd handles login timeouts.

When a client connects to sshd, an alarm is set for LoginGraceTime (default 120 seconds). If the client doesn’t authenticate within this time, SIGALRM is delivered to the sshd process, and the signal handler grace_alarm_handler() is called. This handler calls cleanup_exit(), which performs cleanup and terminates the connection.

The race condition: cleanup_exit() calls functions that are not async-signal-safe — functions that can be interrupted by another signal and that call malloc(), free(), and other non-reentrant functions. If a signal (like SIGCHLD) is delivered at precisely the right moment while grace_alarm_handler() is executing, the heap allocator internal state can be corrupted in a controlled way:

Timeline of race condition:
1. sshd client process starts; LoginGraceTime alarm set
2. LoginGraceTime expires; SIGALRM delivered
3. grace_alarm_handler() begins, calls cleanup_exit()
4. cleanup_exit() calls syslog() (not async-signal-safe)
5. syslog() calls malloc() internally
6. SIGCHLD delivered DURING malloc() execution in syslog()
7. SIGCHLD handler also calls async-unsafe functions
8. Heap state corrupted due to re-entrant malloc() call

This is a classic TOCTTOU (Time Of Check To Time Of Use) race that corrupts heap allocator metadata. With careful timing and repeated attempts, attackers can craft a heap state that, when a specific operation executes, redirects program counter to attacker-controlled data.

The exploitation is probabilistic — thousands of connection attempts may be needed to win the race condition. On a default system, Qualys estimated approximately 10,000 attempts over several hours would be needed. This makes exploitation noisy but not impractical:

# Conceptual exploitation loop
for i in $(seq 1 10000); do
    ssh -o ConnectTimeout=1 target_ip &
done

The vulnerability primarily affects glibc-based Linux systems. OpenBSD (where OpenSSH originates), macOS, and non-glibc Linux distributions have different memory allocator implementations that may not be exploitable via the same technique.

Real-World Exploitation Evidence

CISA added CVE-2024-6387 to its KEV catalogue shortly after disclosure, confirming observed exploitation. Key factors:

• Scope: Qualys estimated 14 million potentially vulnerable internet-facing OpenSSH server instances as of disclosure.
• PoC availability: Multiple public proof-of-concept exploits were published within days of the advisory.
• Targeted exploitation: While mass exploitation is difficult due to the probabilistic nature, targeted exploitation by well-resourced actors has been documented.
• Shodan scale: Security scanners confirmed millions of vulnerable sshd instances reachable from the internet.

The CVSS score of 8.1 (High rather than Critical) reflects the complexity of reliable exploitation — the race condition makes it harder to exploit reliably than typical memory corruption vulnerabilities, but it is clearly exploitable in practice.

Impact Assessment

Successful exploitation yields:

• Unauthenticated root shell: sshd runs as root; exploitation provides a root shell on the target system.
• No credentials needed: The vulnerability is in the pre-authentication code path; no SSH credentials are required.
• Complete system compromise: Root access enables all subsequent actions — data theft, malware installation, lateral movement, persistence.
• Scale of exposure: The sheer ubiquity of OpenSSH means the total number of potentially vulnerable systems is in the millions.

The mitigating factor is that exploitation typically requires thousands of connection attempts, which should be detectable in SSH logs as connection flooding.

Affected Versions

Linux distribution status at time of disclosure (July 2024):

• Debian 12 (Bookworm): Vulnerable (OpenSSH 9.2p1)
• Ubuntu 22.04 LTS: Vulnerable (OpenSSH 8.9p1)
• Amazon Linux 2023: Vulnerable
• RHEL 9 / CentOS 9: Not vulnerable (ships 8.7p1 with backported fix)
• OpenBSD: Not vulnerable (different architecture)

Remediation Steps

1. Upgrade OpenSSH to 9.8p1 or later:

   # Debian/Ubuntu
   apt update && apt install openssh-server
   
   # RHEL/Rocky/AlmaLinux
   dnf update openssh-server
   
   # Verify version
   sshd -V

2. Set LoginGraceTime to 0 as interim workaround: Setting LoginGraceTime 0 in sshd_config disables the SIGALRM-based timeout, eliminating the vulnerable code path. Note: this disables unauthenticated connection timeouts, which has minor DoS implications.

   # /etc/ssh/sshd_config
   LoginGraceTime 0

   Then restart: systemctl restart sshd

3. Restrict SSH access: Limit SSH access to known IP ranges using AllowUsers / AllowGroups, firewall rules, or TCP wrappers. This doesn’t fix the vulnerability but dramatically reduces exploitability.

4. Enable connection rate limiting: Use MaxStartups to limit concurrent unauthenticated connections (exploitation requires many simultaneous attempts):

   # /etc/ssh/sshd_config
   MaxStartups 10:30:100

Detection Guidance

Log sources:

• /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL)
• /var/log/syslog for sshd crash/restart events
• Network flow logs for SSH connection rate

Suspicious patterns:

# High volume of SSH connection attempts (exploitation indicator)
grep "Connection from" /var/log/auth.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head

# Repeated disconnects/timeouts
grep "Timeout before authentication" /var/log/auth.log | wc -l

# SSHD crashes (may indicate exploitation attempts)
grep "signal 11" /var/log/syslog | grep sshd

Suricata signature:

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"OpenSSH CVE-2024-6387 regreSSHion Mass Connection Attempt"; flow:to_server; flags:S; threshold:type both, track by_src, count 100, seconds 60; sid:9000638; rev:1;)

Timeline