A newly discovered vulnerability in OpenSSH nicknamed regreSSHion allows remote attackers to gain root privileges on Linux systems based on glibc library. This flaw enables an unauthenticated attacker to execute arbitrary code on the vulnerable system and obtain root privileges. Considering the wide application of OpenSSH, this flaw can have massive impact, comparable in size with an infamous Log4Shell.
RegreSSHion OpenSSH Vulnerability
On July 1, 2024, cybersecurity experts from Qualys disclosed a critical vulnerability in OpenSSH, that was named RegreSSHion. It has been assigned the identifier CVE-2024-6387 and allows remote code execution (RCE) with root privileges on servers and user PCs running *nix systems with the standard Glibc library. The vulnerability affects versions below 4.4 and above 8.5. Experts tested the vulnerability in laboratory conditions on 32-bit Linux systems with ASLR (Address Space Layout Randomization) protection enabled.
The results of these evaluations are not promising for the defenders. To exploit the vulnerability successfully, an alleged hacker would need 6-8 hours of continuous attempts to establish a connection to the server with the maximum allowed sshd configuration intensity. I.e., one attack involves around 10,000 attempts, making it quite challenging to carry out. While the vulnerability can theoretically be exploited on 64-bit systems, it may take significantly longer, up to one week. Moreover, experts have not demonstrated a working exploit for such systems.
Commonly accessible network scanning engines report about over 14 million vulnerable systems exposed to the Internet. Considering that there is always an error to the lower side, the actual number may exceed 15 million devices.
Technical Details
The essence of the vulnerability lies in bypassing client authentication during the LoginGraceTime period. During an SSH authentication attempt, the user has a time limit to complete the process, which defaults to 120 seconds. If successful, the sshd SIGALRM handler is triggered, which calls functions that are not safe for asynchronous signals, such as syslog(). If an attacker initiates multiple connections to the target OpenSSH server, repeatedly triggering the LoginGraceTime timeout without completing authentication, this will cause the server to raise a SIGALRM signal. And triggering the SIGALRM signal, in turn, interrupts specific code in sshd, and can lead to execution state corruption.
The exploit relies on interrupting the server’s signal handler precisely when it is performing non-asynchronous signal-safe operations. As mentioned above, the attacker needs to send specially crafted input approximately 10,000 times, which manipulates the server’s memory layout, causing heap corruption. During exploitation, the attacker adjusts the input timing based on feedback from previous attempts. If successful, this allows them to overwrite critical memory structures. This ultimately grants the attacker remote control of the server with root privileges and the ability to execute arbitrary code.
An Old New Vulnerability
This vulnerability isn’t entirely new. Technically, it is a regression of the previously identified CVE-2006-5051, which was patched in version 4.4 back in 2006. The name “regreSSHion” that this vulnerability was instantly coined with references exactly this – being a regression bug affecting OpenSSH. The previous one also included a signal handler race condition in OpenSSH. This could theoretically lead to a denial of service or potentially allow remote code execution. The research shows that the reason the old vulnerability resurfaced hides in the changed made during the development of OpenSSH 8.5. The block “#ifdef DO_LOG_SAFE_IN_SIGHAND” was mistakenly removed from the sigdie() function, which is directly called from the SIGALRM handler.
Potential Risk
Remote code execution vulnerabilities are always among the most severe ones, often hitting Critical and Severe CVSS scores. RegreSSHion is not an exclusion, as it may allow hackers to get into pretty much any system, having no foothold whatsoever. Aside from being a perfect entry point for a cyberattack, RCE flaws may as well serve for performing lateral movement.
The versions at risk are those prior to 4.4p1 and between 8.5p1 and 9.8p1. A silver lining here is that due to the technical complexity of executing the attack, widespread exploitation is unlikely. Additionally, the attacker must know which Linux version is running on the server. For example, OpenSSH on OpenBSD is not affected, as it has had a protection mechanism since 2001 that blocks such classes of attacks. Also, if the server already has some form of protection against brute force and DDoS attacks, the attack is likely to be blocked. In other systems based on standard libraries other than Glibc, theoretically, it may be possible to adapt the method for an attack.
Fortunately for the massive amount of OpenSSH users, a patch has already been released to fix the vulnerability. Administrators and users need to update SSHD to version 9.8p1. If updating is not possible, experts recommend setting the LoginGraceTime parameter to 0. However, this could also lead to a denial of service if all connection slots become occupied.
