high CVSS 8.1 Public exploit available

CVE-2024-6387·OpenSSH vulnerability

A security regression (CVE-2006-5051) was discovered in OpenSSH's server (sshd). There is a race condition which can lead sshd to handle some signals in an unsafe manner. An unauthenticated, remote attacker may be able to trigger it by failing to authenticate within a set time period.

Severity
high
Software
OpenSSH
Fixed in
4.4
Published
2024-07-01

Affected versions

From: 11.0.0

Until: 10.0.0

Fixed in: 4.4

How to fix this CVE

Upgrade OpenSSH to version 9.8p1 or later immediately. If patching is not immediately possible, set LoginGraceTime to 0 in sshd_config as a temporary mitigation (this prevents the race condition but makes sshd vulnerable to connection exhaustion DoS). Restrict SSH access to trusted IP ranges using firewall rules.

apk update && apk upgrade openssh
# Verify: sshd -V
rc-service sshd restart

Defensia detects this vulnerability

What an exploitation attempt looks like

Sample log line indicative of exploitation attempts:

The attacker opens SSH connections and lets them timeout without completing authentication. During the SIGALRM handler triggered by LoginGraceTime expiry, a race condition allows the attacker to corrupt sshd's heap. Exploitation requires thousands of connection attempts (typically 6-8 hours on 32-bit systems) but is fully unauthenticated and achieves root-level RCE. Network signature: high volume of SSH connections that never complete authentication from the same source IP.

WAF mitigation (if patching is not yet possible)

Add this rule to your WAF to block exploitation attempts while you schedule the patch. 

WAF rules cannot directly mitigate SSH-level vulnerabilities. Network-level mitigations include:
- Rate-limit new SSH connections: iptables -A INPUT -p tcp --dport 22 -m connlimit --connlimit-above 10 -j DROP
- Restrict SSH to known IPs: iptables -A INPUT -p tcp --dport 22 -s TRUSTED_CIDR -j ACCEPT
- Use fail2ban or similar to detect connection floods
- Deploy a bastion/jump host to limit SSH exposure

How to check if you are affected

  1. Check OpenSSH version: sshd -V — vulnerable if 8.5p1 through 9.7p1 (also 4.4p1 and earlier)
  2. Check LoginGraceTime setting: grep LoginGraceTime /etc/ssh/sshd_config (default 120s is vulnerable, 0 mitigates)
  3. Monitor for exploitation attempts: grep 'Timeout before authentication' /var/log/auth.log | wc -l
  4. Check for connection floods to port 22: ss -tn state syn-recv sport = :22 | wc -l
  5. Audit SSH access logs for mass unauthenticated connections: awk '/sshd.*Connection closed.*preauth/ {print}' /var/log/auth.log | tail -20
  6. Verify ASLR is enabled (makes exploitation harder on 64-bit): cat /proc/sys/kernel/randomize_va_space (should be 2)

Indicators of compromise

  • High volume of SSH connections from a single IP that never complete authentication
  • Repeated 'Timeout before authentication' messages in auth.log from the same source
  • SSH daemon crashes or unexpected restarts
  • Abnormal heap corruption in sshd process memory
  • Thousands of SYN packets to port 22 in short time windows

FAQ

Is regreSSHion exploitable on 64-bit systems?

Exploitation is significantly harder on 64-bit systems due to ASLR providing much more entropy (requiring potentially millions of attempts). The original research demonstrated exploitation on 32-bit glibc-based Linux. However, do not rely on ASLR alone — patch immediately regardless of architecture.

Why is it called regreSSHion?

It is a regression of CVE-2006-5051, a vulnerability that was fixed 18 years ago. The fix was accidentally removed in OpenSSH 8.5p1 (March 2021), reintroducing the same class of vulnerability. The name is a portmanteau of 'regression' and 'SSH'.

Does setting LoginGraceTime to 0 fully fix the issue?

Setting LoginGraceTime to 0 prevents the race condition from being triggered (no timeout signal is sent), but it makes sshd susceptible to connection exhaustion DoS since connections are never timed out. It is a temporary workaround, not a permanent fix.

Are SSH clients affected?

No. This vulnerability only affects the OpenSSH server (sshd). SSH clients (ssh) are not vulnerable. Only servers accepting SSH connections need to be patched.

Does this affect OpenSSH on BSD or macOS?

The vulnerability exists in the code on all platforms, but the demonstrated exploitation technique targets Linux glibc's malloc implementation. BSD and macOS use different allocators, making exploitation different and potentially harder, but they should still be patched.

Can I detect active exploitation?

Look for a high rate of failed/timed-out SSH authentication attempts from a single source IP. The attacker needs thousands of connections, so it produces a detectable pattern in auth.log and network monitoring. Rate-limiting SSH connections is both detection and mitigation.

References

Track CVEs across your fleet automatically

Defensia scans your Linux servers and tells you exactly which ones are running vulnerable versions — including CVE-2024-6387. Free for 1 server.

Get started free