regreSSHion: CVE-2024-6387 OpenSSH Remote Code Execution

On July 1, 2024, Qualys disclosed CVE-2024-6387, a critical unauthenticated remote code execution vulnerability in OpenSSH server (sshd). They named it "regreSSHion" because it is a regression of CVE-2006-5051, a vulnerability that was patched eighteen years ago and accidentally reintroduced in October 2020 with OpenSSH 8.5p1.

The vulnerability affects OpenSSH versions 8.5p1 through 9.7p1 on glibc-based Linux systems. Given that OpenSSH is installed on virtually every Linux server on the internet, the potential attack surface is enormous. Qualys identified approximately 14 million potentially vulnerable OpenSSH instances exposed to the internet via Shodan and Censys.

Technical Details

The vulnerability is a signal handler race condition in sshd's authentication timeout mechanism.

When a client connects to sshd, the server sets an alarm (via the SIGALRM signal) for the LoginGraceTime period, which defaults to 120 seconds. If the client has not authenticated by the time this alarm fires, sshd's signal handler is invoked to clean up the connection.

The problem is that this signal handler calls functions that are not async-signal-safe. Specifically, it calls syslog() for logging, which internally calls malloc() and free(). If the SIGALRM fires while sshd's main code is also in the middle of a malloc() or free() call, the heap metadata can be corrupted in an exploitable way.

This is a classic signal handler reentrancy issue. The original CVE-2006-5051 was fixed by ensuring the signal handler only set a flag, with the actual cleanup happening in the main execution flow. But a code refactor in OpenSSH 8.5p1 (commit D1310B2) inadvertently removed the conditional check that prevented the unsafe code path from being reached in the signal handler.

Exploitation Complexity

Qualys demonstrated a working exploit against OpenSSH 9.2p1 on Debian with a 32-bit glibc. The exploit is not trivial:

• It requires winning a race condition, which on average takes approximately 10,000 connection attempts.
• At the default MaxStartups rate of 100 connections, exploitation takes roughly 6-8 hours.
• The exploit is architecture-dependent. The 32-bit glibc exploit does not directly translate to 64-bit systems due to ASLR providing a significantly larger address space (requiring brute-forcing a 32-bit address space versus a much larger one on amd64).
• On systems with ASLR enabled on 64-bit, Qualys estimated exploitation could take days to weeks of sustained connection attempts.

Despite this complexity, the vulnerability should be treated as critical for several reasons:

1. Pre-authentication: No credentials are required. The attacker only needs network access to sshd.
2. Root-level execution: sshd typically runs as root, so successful exploitation yields immediate root access.
3. Widespread exposure: SSH is exposed to the internet on millions of servers.
4. Exploit improvement is likely: The initial PoC is slow, but exploit refinement by sophisticated actors is expected.

Affected Versions

• Vulnerable: OpenSSH 8.5p1 through 9.7p1 (on glibc-based Linux)
• Not vulnerable: OpenSSH versions prior to 4.4p1 (unless patched for CVE-2006-5051)
• Not vulnerable: OpenSSH 4.4p1 through 8.4p1 (the original fix was present)
• Fixed in: OpenSSH 9.8p1 (released July 1, 2024)
• Not affected: OpenBSD (OpenBSD's sshd has a different signal handling mechanism)

Systems using musl libc (such as Alpine Linux) are not exploitable with the published technique because musl's malloc() implementation differs, but they should still be patched as other exploitation paths may exist.

Detection and Mitigation

Patch immediately. OpenSSH 9.8p1 was released concurrently with the disclosure. Major Linux distributions (Ubuntu, Debian, RHEL, SUSE) released patched packages within 24-48 hours.

If immediate patching is not possible, the following mitigations reduce risk:

Set LoginGraceTime to 0: This disables the authentication timeout entirely, which eliminates the SIGALRM signal handler race condition. However, this means unauthenticated connections will persist indefinitely, potentially enabling denial-of-service.

# /etc/ssh/sshd_config
LoginGraceTime 0

Restrict SSH access: Use firewall rules, network segmentation, or tools like fail2ban to limit which IP addresses can reach sshd. This does not fix the vulnerability but reduces the attack surface.

Monitor for exploitation attempts: The exploit requires thousands of connection attempts. Monitoring for anomalous SSH connection volumes, specifically high rates of connections that are initiated but never authenticated, can indicate exploitation attempts.

Detection signatures to look for:

• High volume of connections from a single source IP to port 22 that disconnect without authenticating.
• Connection rates exceeding 10-20 per second from a single source.
• sshd log entries showing "Timeout before authentication" at unusually high rates.

The Regression Problem

What makes this vulnerability particularly noteworthy is its origin. It was not a new bug introduced by new functionality. It was a previously fixed bug that was reintroduced by a code refactor.

This highlights a systemic problem in software maintenance: regression testing for security fixes is often inadequate. When CVE-2006-5051 was fixed, there was presumably no regression test that would catch a reintroduction of the vulnerable code pattern. When the code was refactored in 2020, the developer had no way of knowing that a specific conditional check was the linchpin of an 18-year-old security fix.

This pattern is not unique to OpenSSH. The Linux kernel has experienced similar regressions. Application codebases routinely reintroduce previously fixed SQL injection, XSS, and buffer overflow vulnerabilities during refactoring.

The solution is not just better code review (though that helps). It requires:

1. Security regression tests: Every security fix should have an accompanying test that validates the fix is in place. This test should be designed to fail if the vulnerable code pattern is reintroduced.
2. Security-critical code annotations: Code that exists specifically to mitigate a vulnerability should be annotated as such, so that future developers know not to modify or remove it without understanding the security implications.
3. Dependency tracking for fixes: Organizations should track which CVE fixes are present in their codebase and verify their continued presence after major refactors.

Timeline

• 2006: CVE-2006-5051 discovered and patched in OpenSSH 4.4p1.
• October 2020: OpenSSH 8.5p1 inadvertently reintroduces the vulnerability.
• Early 2024: Qualys identifies the regression during a security audit.
• May 2024: Qualys privately discloses to OpenSSH developers.
• July 1, 2024: Coordinated disclosure and release of OpenSSH 9.8p1.

How Safeguard.sh Helps

regreSSHion is a textbook case for why continuous software composition analysis matters.

• SBOM-based vulnerability matching identifies every instance of OpenSSH in your environment, across servers, containers, and embedded systems, so you know exactly where you are exposed before a CVE is even published.
• Version tracking and alerting notifies you when any component in your SBOM falls into a vulnerable version range, enabling rapid triage of vulnerabilities like CVE-2024-6387.
• Regression detection helps you track whether previously patched vulnerabilities have been reintroduced, whether through version downgrades, base image changes, or dependency updates that pull in older versions.
• Remediation prioritization combines CVSS scores with reachability analysis and deployment context to help you focus patching efforts on the instances that are actually exposed to the internet.

With 14 million exposed instances, the race is between defenders patching and attackers refining their exploits. Knowing where OpenSSH lives in your environment is step one.