CVE-2024-6387
OpenSSH regreSSHion — Unauthenticated RCE as Root
Impact: A signal handler race condition in OpenSSH 8.5p1–9.7p1 allows an unauthenticated attacker to execute arbitrary code as root on glibc-based Linux systems. No credentials required. Internet-exposed sshd = direct root shell risk.
Technical Details
Step-by-Step Fix Runbook
ssh -V sshd -V apt-cache policy openssh-server # Debian/Ubuntu rpm -q openssh-server # RHEL/CentOS # Vulnerable: 8.5p1 – 9.7p1 on glibc Linux
# Ubuntu/Debian apt-get update && apt-get install --only-upgrade openssh-server systemctl restart sshd # RHEL/CentOS — check vendor advisory for backport dnf update openssh-server systemctl restart sshd # Verify fix ssh -V # Must show OpenSSH_9.8p1 or later
# sshd_config — set LoginGraceTime to 0 # WARNING: disables grace period, may affect auth on slow connections echo 'LoginGraceTime 0' >> /etc/ssh/sshd_config systemctl reload sshd # Verify sshd -T | grep logingracetime
# Allow only trusted IPs on port 22 ufw allow from 203.0.113.0/24 to any port 22 ufw deny 22 # Or use iptables iptables -A INPUT -p tcp --dport 22 -s 203.0.113.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j DROP
apt-get install fail2ban # /etc/fail2ban/jail.local [sshd] enabled = true maxretry = 3 bantime = 3600 findtime = 600 systemctl enable --now fail2ban
# Look for connection flood patterns (exploitation indicator)
grep 'sshd' /var/log/auth.log | grep -E 'Did not receive|Connection closed|preauth' | tail -50
# Alert on >100 preauth disconnects in 10 minutes
awk '/preauth/{count++} END{if(count>100) print "ALERT: possible exploitation attempt"}' /var/log/auth.logFrequently Asked Questions
Is CVE-2024-6387 being actively exploited?
As of mid-2024, proof-of-concept exploits exist but reliable remote exploitation is difficult — the race condition requires many attempts (potentially thousands) and the exploit window is narrow. However, CVSS 8.1 and unauthenticated RCE as root means patching is non-negotiable. Any internet-exposed sshd running 8.5p1–9.7p1 should be patched or have LoginGraceTime 0 set immediately.
Does the LoginGraceTime 0 workaround fully mitigate regreSSHion?
Setting LoginGraceTime 0 prevents the signal handler race condition by eliminating the grace period entirely. This is an effective temporary mitigation but has trade-offs: authentication failures on slow or high-latency connections may increase. It is NOT a substitute for patching to OpenSSH 9.8p1+ — apply the workaround only while preparing the upgrade.
How do I tell if my system was compromised via CVE-2024-6387?
Indicators of compromise: 1) Large number of 'Did not receive identification string' or 'Connection closed by ... preauth' entries in auth.log (thousands in short time). 2) Unexpected new user accounts or SSH keys in authorized_keys. 3) Unusual cron jobs or systemd units. 4) Outbound connections to unexpected IPs. 5) Changes to /etc/passwd or sudoers. Run a full AIDE/Tripwire integrity check after the patch.
Does this affect macOS or Windows OpenSSH?
CVE-2024-6387 affects glibc-based Linux systems only. macOS uses libSystem (not glibc) — Apple released a separate advisory. Windows OpenSSH (Microsoft's port) is not affected. BSDs are not affected. The vulnerability requires specific signal handler behavior in glibc's async-signal-safe environment.