A severe vulnerability in OpenSSH, dubbed “regreSSHion” (CVE-2024-6387), has been discovered by the Qualys Threat Research Unit, potentially exposing millions of systems to remote code execution attacks. This flaw, in versions 8.5p1 through 9.7p1 of Portable OpenSSH, allows an unauthenticated attacker to execute code on a remote Linux machine with root privileges.
According to Qualys, over 14 million OpenSSH server instances exposed to the internet could be vulnerable. Their analysis of anonymized data reveals that approximately 700,000 external internet-facing instances within their global customer base are at risk, accounting for 31% of all internet-facing instances with OpenSSH. Bharat Jogi, Senior Director of Threat Research at Qualys, noted that this flaw affects sshd in its default configuration on glibc-based Linux systems.
Qualys decided not to publicly publish a working prototype of the exploit until the vulnerability is widely fixed. However, a detailed description of the vulnerability is available, making the development of third-party exploits likely a matter of time.
(Update: The said exploits are now circulating the open web.)
The vulnerability stems from a signal handler race condition in the OpenSSH server (sshd).
A critical vulnerability in sshd(8) was present in Portable OpenSSH versions between 8.5p1 and 9.7p1 (inclusive) that may allow arbitrary code execution with root privileges. Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with ASLR. Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept.
The OpenSSH Team
Race conditions occur when multiple processes or threads compete to access and manipulate shared data concurrently, potentially leading to unpredictable and erroneous results. In the context of this vulnerability, the race condition involves the signal handler, a critical component responsible for managing system interrupts. This particular flaw allows an attacker to exploit the brief window of time between when a signal is received and when it’s processed, potentially manipulating the system’s state to execute malicious code.
While such vulnerabilities are notoriously difficult to consistently exploit due to their timing-dependent nature, the potential for root-level access makes this a severe security risk, especially given the widespread use of OpenSSH in enterprise environments.
How it happened & fixes
The vulnerability stems from a regression introduced in OpenSSH 8.5, causing a race condition in the sshd signal handling code. This regression removed protection against the old CVE-2006-5051 vulnerability, which existed in OpenSSH versions before 4.4 (2006) and was considered “theoretical”. The issue occurred when the “#ifdef DO_LOG_SAFE_IN_SIGHAND” block was mistakenly removed from the sigdie() function during OpenSSH 8.5 development. The SIGALRM handler directly calls this function.
The SIGALRM handler in sshd is triggered asynchronously if the client fails to authenticate within the connection timeout (LoginGraceTime, set to 120 seconds by default).
The vulnerability arises because the signal handler calls functions that are unsafe for asynchronous signal handling, such as syslog(). In Glibc, syslog() is not designed for use in asynchronous signal handlers since it calls malloc() and free(). When the SIGALRM signal interrupts sshd code execution, it can disrupt the execution state. An exploit leverages this by timing the interruption of critical code. Notably, OpenBSD is unaffected because it uses syslog_r() in the SIGALRM handler, which is specifically designed for asynchronous operation.
While exploitation on 64-bit systems is believed to be possible, it has not yet been demonstrated. The OpenSSH team warns that attack methods will likely improve over time, potentially increasing the risk to vulnerable systems.
OpenSSH also said that systems running non-glibc libraries or those with modified ASLR settings may be at higher risk. Interestingly, they also pointed out that some downstream Linux distributions have altered OpenSSH to disable per-connection ASLR re-randomization, a practice they described as puzzling.
The OpenSSH team has released version 9.8 to address this vulnerability and make other security improvements. You can track the release of package updates in distributions on these pages: Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, Arch, and FreeBSD .
To mitigate the vulnerability (according to this patch), you can set the “LoginGraceTime=0” parameter in sshd_config. However, disabling this timeout can make initiating a denial of service attack easier by establishing numerous connections that exceed the MaxStartups parameter limits. A common sign of such an attack is the frequent appearance of “Timeout before authentication” entries in the log.
