regreSSHion: CVE-2024-6387 and the Return of an 18-Year-Old OpenSSH Bug

Overview

In July 2024, Qualys Threat Research Unit published details of CVE-2024-6387, a critical unauthenticated remote code execution vulnerability in OpenSSH. Dubbed regreSSHion, it carries a CVSS score of 8.1 and affects glibc-based Linux systems running OpenSSH versions 8.5p1 through 9.7p1.

What makes this vulnerability particularly notable is its origin: it is a regression of CVE-2006-5051, a signal handler race condition that was fixed 18 years earlier and accidentally reintroduced in OpenSSH 8.5p1 (released in 2021).

Estimates at disclosure placed over 14 million internet-exposed OpenSSH servers in the vulnerable range.

Understanding the Vulnerability

Signal Handler Race Conditions

OpenSSH implements a LoginGraceTime timeout — if a client connects but does not complete authentication within that window (default: 120 seconds), the server terminates the connection by calling SIGALRM. The vulnerability lives in the asynchronous signal handler for SIGALRM.

Signal handlers must only call async-signal-safe functions. Functions like malloc, free, and syslog are not async-signal-safe. If a signal arrives while one of these functions is mid-execution (e.g., modifying heap metadata), re-entering it from the signal handler corrupts heap state — a classic TOCTOU/race condition.

/* Simplified vulnerable signal handler path in sshd */
static void
grace_alarm_handler(int sig)
{
    /* syslog is NOT async-signal-safe */
    syslog(LOG_INFO, "Timeout before authentication");
    /* graceful_exit also calls non-safe functions */
    graceful_exit(255);
}

The original CVE-2006-5051 fix removed the unsafe call. The 2021 regression silently reintroduced it through a code refactor that moved cleanup logic into the signal handler path.

Exploitation Path

Exploiting this is non-trivial. Successful exploitation requires:

1. Winning a race — the attacker must trigger SIGALRM at precisely the right moment during a heap operation inside sshd.
2. Heap grooming — the attacker shapes the heap layout beforehand by establishing and dropping connections in specific patterns to position allocations predictably.
3. ASLR bypass — on 64-bit systems with ASLR enabled, a brute-force approach across 32-bit address space randomization is required, typically requiring thousands of connection attempts.

Qualys demonstrated a proof-of-concept achieving root RCE on 32-bit Linux systems. On 64-bit systems, exploitation is theoretically possible but significantly harder due to the wider ASLR entropy (48-bit virtual address space).

# Indicative scan for vulnerable sshd versions
nmap -p 22 --script ssh2-enum-algos -sV <target>
# OpenSSH versions 8.5p1 - 9.7p1 on glibc Linux are vulnerable

Why This Is Serious Even If "Hard"

Difficulty is not impossibility. Nation-state actors and well-resourced criminal groups routinely invest in exploiting "hard" bugs when the payoff is unauthenticated root on a server. The key threat model here is:

• No authentication required — the bug is reachable before login
• Root process — sshd listens as root by default
• Mass exposure — SSH is exposed directly on millions of servers
• No user interaction — entirely network-triggered

Detection

Identify Vulnerable OpenSSH Versions

# Check local sshd version
sshd -V
ssh -V

# Remote banner grab
nc <host> 22

# Scan internal network
nmap -p 22 -sV --open 192.168.0.0/24 | grep "OpenSSH [89]\."

Vulnerable range: OpenSSH 8.5p1 to 9.7p1 on glibc-based Linux.
Not affected: OpenSSH on OpenBSD, macOS, or musl-based systems (Alpine Linux, etc.).

Log-Based Detection

Exploitation attempts generate high volumes of failed/incomplete connections. Monitor for:

# /var/log/auth.log patterns indicating brute-force race exploitation
sshd[PID]: Timeout before authentication for <IP> port <port>
sshd[PID]: Connection closed by <IP> port <port> [preauth]

A sudden spike in [preauth] disconnects or Timeout before authentication messages from a single source is a strong indicator of exploitation attempts.

SIEM Detection Rule (Sigma)

title: regreSSHion Exploitation Attempt
status: experimental
description: High volume of pre-auth SSH timeouts from a single source
logsource:
  product: linux
  service: auth
detection:
  keywords:
    - 'Timeout before authentication'
    - '[preauth]'
  timeframe: 60s
  condition: keywords | count(src_ip) > 50
falsepositives:
  - Misconfigured SSH clients
  - Network scanners
level: high

Mitigation

Immediate: Patch OpenSSH

The fix is available in OpenSSH 9.8p1, released the same day as disclosure.

# Debian/Ubuntu
sudo apt update && sudo apt install openssh-server

# RHEL/AlmaLinux/Rocky
sudo dnf update openssh-server

# Verify version after update
sshd -V

Workaround: Reduce LoginGraceTime

If patching immediately is not possible, reducing LoginGraceTime to zero in /etc/ssh/sshd_config eliminates the vulnerable code path:

# /etc/ssh/sshd_config
LoginGraceTime 0

Note: Setting LoginGraceTime 0 means unauthenticated connections are never timed out — this can be abused for connection exhaustion. Apply network-level rate limiting alongside this workaround.

# Rate limit SSH connections at the firewall (iptables example)
iptables -A INPUT -p tcp --dport 22 -m state --state NEW \
  -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW \
  -m recent --update --seconds 60 --hitcount 10 --name SSH -j DROP

Defense in Depth

• Place SSH behind a VPN or bastion host where possible
• Disable password authentication; require public key auth
• Use AllowUsers / AllowGroups to restrict who can attempt SSH
• Enable MaxStartups throttling to limit unauthenticated concurrent connections

# /etc/ssh/sshd_config recommended hardening
PasswordAuthentication no
PermitRootLogin no
MaxStartups 10:30:60
MaxAuthTries 3

Lessons: Regression Testing in Security-Critical Software

regreSSHion illustrates a failure mode that is easy to overlook in secure development programs: regression. A fix applied in 2006 was undone by routine code maintenance in 2021 with no security review of the signal handler behavior change.

Key takeaways for development and security teams:

• Tag security-critical fixes in version control so future refactors trigger review
• Include negative test cases for previously patched vulnerabilities in CI/CD pipelines
• Audit async-signal-safety whenever signal handlers are modified
• Track regressions in CVE databases and advisories as first-class vulnerability events

OpenSSH is among the most audited open-source projects in existence. If a regression like this can persist for three years there, it can happen anywhere.

Conclusion

CVE-2024-6387 is a reminder that even mature, well-maintained codebases carry latent risk. The vulnerability is difficult to exploit reliably, but the combination of no authentication requirement, root privilege, and mass internet exposure makes it a priority patch regardless of perceived exploitation complexity. Organizations should patch to OpenSSH 9.8p1 immediately and adopt the hardening recommendations above as baseline configuration.