CVE-2024-6387: regreSSHion — OpenSSH RCE After 18 Years

A race condition in OpenSSH's signal handler allows unauthenticated attackers to execute arbitrary code as root on Linux servers running glibc. Dubbed "regreSSHion" — a regression of CVE-2006-5051 that was accidentally reintroduced in 2020. Affects approximately 14 million internet-exposed SSH servers. CVSS 8.1 HIGH.

What Is CVE-2024-6387?

CVE-2024-6387 is a signal handler race condition in OpenSSH's server (sshd). When a client does not authenticate within the LoginGraceTime (default: 120 seconds), sshd calls SIGALRM to terminate the connection. The signal handler calls async-signal-unsafe functions — specifically syslog() — which can corrupt heap state when called concurrently with other operations.

Qualys researchers who discovered the vulnerability named it "regreSSHion" because an identical bug (CVE-2006-5051) was fixed in 2006, but the fix was inadvertently removed when OpenSSH 8.5p1 was released in October 2020 — meaning the vulnerability silently re-existed for nearly four years before discovery.

Affected Versions

glibc requirement: The Qualys PoC exploited glibc's malloc implementation. OpenBSD's sshd is not vulnerable. Alpine Linux (which uses musl libc) and macOS are not vulnerable to the demonstrated exploitation technique, though the race condition still exists.

The Race Condition Explained

Signal handlers in C programs must only call "async-signal-safe" functions — a small subset of libc functions that are safe to call from within a signal handler because they don't use shared state. The syslog() function is not async-signal-safe because it uses malloc internally.

# The problematic code path (simplified):
# When LoginGraceTime expires:
SIGALRM → grace_alarm_handler() → syslog() → malloc() internally
                                              ↕ RACE
           main sshd thread also calls        malloc() / free()

# If both malloc operations interleave:
# → Heap corruption
# → With enough attempts: controlled heap layout
# → Remote code execution as root

Exploitation requires winning the race condition reliably, which requires thousands of connection attempts over minutes. This makes automated exploitation at internet scale somewhat slower than typical "fire and forget" vulns — but sophisticated actors with persistent access to a target have plenty of time.

Exploitation Difficulty

Qualys demonstrated reliable exploitation on 32-bit systems (x86). On 64-bit systems, ASLR significantly increases difficulty. The researchers note that with ~10,000 attempts over 6-8 hours, exploitation is theoretically achievable on 64-bit systems, but they did not publish a working PoC for x86_64.

However, the bar can be lowered by:

• Information leaks that defeat ASLR (combined exploits)
• Brute-forcing in environments where fail2ban or rate limiting isn't configured
• Future research improving the exploitation technique
• Access to vulnerable 32-bit systems (still common in IoT and embedded Linux)

Detection

# Check OpenSSH version
ssh -V
sshd -V

# Check installed package version (Debian/Ubuntu)
dpkg -l openssh-server | grep openssh

# Check installed package version (RHEL/CentOS)
rpm -qa | grep openssh-server

# Check for brute-force attempts indicative of regreSSHion exploitation
# (very high connection rate from single IP, all failing within grace period)
grep "Connection closed by" /var/log/auth.log | 
  awk '{print $9}' | sort | uniq -c | sort -rn | head -20

# Check for failed logins at high rate
grep "Failed\|Invalid" /var/log/auth.log | 
  awk '{print $11}' | sort | uniq -c | sort -rn | head -10

Mitigation

1. Update OpenSSH to 9.8p1+: All major distributions released patches within days of disclosure. apt update && apt upgrade openssh-server or equivalent.
2. Set LoginGraceTime to 0: Setting LoginGraceTime 0 in /etc/ssh/sshd_config prevents the SIGALRM handler from being called, eliminating the race condition (though it removes the grace timeout):

   echo "LoginGraceTime 0" >> /etc/ssh/sshd_config
   systemctl reload sshd

3. Rate limit SSH connections: Configure fail2ban or iptables rate limiting to prevent the thousands of connections needed for exploitation
4. Restrict SSH access by IP: Limit sshd to known management IP ranges using AllowUsers, ListenAddress, or firewall rules
5. Use SSH keys only: Disable password authentication — key-based auth adds a strong pre-authentication filter
6. Consider moving SSH to non-standard port: Reduces opportunistic scanner noise, though not a security control

KENSAI Detection Capability

• SSH banner scanning: KENSAI identifies OpenSSH versions across all internet-facing assets, flagging 8.5p1–9.7p1 as vulnerable to CVE-2024-6387
• Internal network scanning: Comprehensive discovery of vulnerable SSH servers on internal networks
• Configuration audit: Checks for mitigating configurations (LoginGraceTime, AllowUsers, key-only auth)
• Patch validation: Confirms patch application after remediation
• Exposure context: Prioritizes internet-exposed SSH servers over internal-only systems