NAVANEM
CVE-2024-6387

OpenSSH server (sshd), signal handler race leading to pre-auth RCE (regreSSHion)

A signal handler race condition was found in OpenSSH's server (sshd), where a client does not authenticate within LoginGraceTime seconds (120 by default), then sshd's SIGALRM handler is called asynchronously, but this signal handler calls various functions that are not async-signal-safe.

Overview

CVE-2024-6387, dubbed "regreSSHion," is a critical signal handler race condition vulnerability in OpenSSH's server daemon (sshd). Discovered by the Qualys Threat Research Unit, this vulnerability allows unauthenticated remote attackers to potentially achieve pre-authentication remote code execution (RCE) as root on affected glibc-based Linux systems. The vulnerability is a regression of CVE-2006-5051, which was previously patched but reintroduced in OpenSSH 8.5p1.

Technical Details

The vulnerability exists in sshd's handling of the LoginGraceTime timeout mechanism. When a client fails to authenticate within the configured LoginGraceTime period (default 120 seconds), sshd's SIGALRM signal handler is invoked asynchronously. The flaw occurs because this signal handler calls functions such as syslog() that are not async-signal-safe.

When these unsafe functions are called from a signal handler context while the main program is in the middle of operations that modify global state (such as heap memory management), memory corruption can occur. The Qualys team demonstrated that on 32-bit glibc Linux systems, this race condition can be reliably won within approximately 6-8 hours of sustained connection attempts, resulting in pre-authentication RCE as root. On 64-bit glibc systems, exploitation is significantly more difficult, estimated at approximately one week of continuous attack traffic per target host.

Impact

This vulnerability represents a worst-case scenario for Internet-exposed SSH services. Successful exploitation grants attackers root-level access without requiring any authentication credentials, completely bypassing the authentication layer. Given that OpenSSH is the standard SSH daemon on virtually every Linux server and many network appliances, the potential attack surface is enormous.

While practical exploitation is slow and generates noisy network traffic (requiring thousands of sustained connections), determined attackers targeting high-value systems could succeed. A public proof-of-concept for 32-bit systems exists. As of late 2024, no confirmed in-the-wild exploitation has been reported, though scanning and spray attempts were observed within 48 hours of disclosure.

Mitigation

  1. Patch immediately: Upgrade to OpenSSH 9.8p1 or later. Check distribution security trackers for backported fixes and verify with ssh -V.
  2. Workaround: Set LoginGraceTime 0 in /etc/ssh/sshd_config to disable the SIGALRM trigger (note: this exposes the server to slowloris-style resource exhaustion).
  3. Network restrictions: Limit SSH access to known source IP addresses via firewall rules.
  4. Monitoring: Implement rate limiting and monitor for unusual SSH connection patterns per source IP.

Detection

Monitor SSH connection rates per source IP address, as exploitation requires thousands of connections over extended periods. Anomalous connection flood patterns to port 22 from single sources should trigger alerts. Review sshd logs for excessive authentication timeout events.