Exploits & Vulnerabilities
The Potential Impact of the OpenSSH Vulnerabilities CVE-2024–6387 and CVE-2024-6409
We check the OpenSSH vulnerabilities CVE-2024–6387 and CVE-2024-6409, examining their potential real-world impact and the possibility of exploitation for CVE-2024–6387 in x64 systems.
Save to Folio
Introduction
CVE-2024–6387, also known as “regreSSHion,” is a vulnerability that exists in OpenSSH, a widely-used suite of secure networking utilities based on the SSH protocol. This vulnerability, which was discovered in July 2024, allows for remote unauthenticated code execution, potentially providing attackers root privileges on affected systems. The Common Vulnerability Scoring System (CVSS) has rated this vulnerability with a score of 9.8
The OpenSSH vendor advisory mentions that the successful exploitation of CVE-2024-6387 has been demonstrated on 32-bit Linux and GNU C Library systems with (ASLR). It also mentions that exploitation on 64-bit systems might be possible but this has not been demonstrated at the time of publishing.
On July 8, another similar vulnerability, the signal handler race condition CVE-2024-6409 was discovered. This flaw occurs when a client fails to authenticate within the LoginGraceTime period, which is 120 seconds by default, and 600 seconds in older OpenSSH versions. Consequently, this can lead to a signal handler race condition in the cleanup_exit() function within the child process of the SSHD server.
The “regreSSHion” vulnerability arises from the unsafe handling of the SIGALRM signal during SSH authentication. When the LoginGraceTime expires, the SIGALRM signal is raised, and the corresponding handler performs certain actions, including calling non-async-signal-safe functions like syslog(). This can create a race condition, where the timing of operations could lead to memory corruption or other unexpected behaviours.
SIGALRM is a signal in Unix-like operating systems that indicates an alarm or timer expiration. When a process sets and a function triggers, it schedules a SIGALRM signal to be sent to the process after a specified number of seconds. This signal is commonly used for timing operations, such as implementing timeouts for network requests or scheduling periodic tasks. Processes can define custom signal handlers to respond to SIGALRM, allowing them to perform actions such as terminating processes, resetting timers, or managing execution time limits. Overall, SIGALRM facilitates time-sensitive operations within Unix processes by providing a mechanism to handle scheduled alarms and timing events.
Exploiting CVE-2024–6387 requires an attacker to initiate thousands of connection attempts to trigger the race condition accurately. The process involves repeatedly setting and resetting LoginGraceTime, causing the server to invoke the SIGALRM signal handler. This requires precise timing and proper inputs to manipulate the server’s memory layout, leading to heap corruption and code execution.
Signal handlers are special functions that get called in response to specific signals sent to a programme. These signals can be generated, either by the operating system or by the programme itself. However, not all functions are safe to call from within a signal handler since they may not be reentrant, therefore cannot safely be interrupted and called again (“async-signal-safe”). For instance, syslog() is a function used to log messages to the system logger and is not considered async-signal-safe.
Researchers have found that approximately 10,000 attempts are needed to successfully exploit this vulnerability. While the exploit could take days to complete, it is still not guaranteed that the attempt would be successful. The presence of modern security mechanisms such as Address Space Layout Randomization (ASLR) and No-eXecute (NX) bits further complicate the exploitation process but do not entirely mitigate the risk.
CVE-2024-6409 technical details
Like CVE-2024-6387, this vulnerability occurs when the SSHD’s SIGALRM handler is called asynchronously, which in turn calls various functions that are not async-signal-safe.
The race condition in grace_alarm_handler() calls cleanup_exit() from the privsep child process. However, cleanup_exit() is not designed to be called from a signal handler, potentially invoking unsafe functions. Cleanup function calls can be interrupted by signals, causing unsafe state changes and potential remote code execution (RCE).
As a privsep child process run’s with reduced privileges, there is less reason to worry about the vulnerability. In addition, working exploits for the CVE-2024-6409 have not been yet discovered, therefore proof of its actual exploitation has not been established at the time of publishing.
Exploitability of CVE-2024-6387 in x64 Systems
The OpenSSH vendor advisory mentions that the successful exploitation of CVE-2024-6387 has been demonstrated on 32-bit Linux and GNU C Library (glibc) systems with (ASLR). It also mentions that exploitation on 64-bit systems might be possible. However, certain characteristics of X64 systems make this exploitation much more difficult, which we’ll expound on in this section.
In x64 systems, ASLR plays a crucial role by randomising memory addresses, including those of the GNU C Library (glibc), with each programme execution. This randomness makes it very difficult for attackers to predict the location of the glibc base address, thus mitigating exploits that depend on precise memory targeting. The x64 architecture's expansive address space further complicates exploitation, as attackers have to guess an exponentially greater amount of addresses. Combined with security measures such as stack canaries and NX bits, exploiting vulnerabilities such as CVE-2024-6387 becomes highly impractical on x64 systems.
While theoretically possible under specific conditions, the effective implementation of ASLR and the inherent complexities of the x64 environment significantly reduce real-world exploitability, highlighting the robust security benefits of these architectural safeguards.
Potential impact
Our As per our internal telemetry we did not notice any trend change for CVE-2024–6387, which could be considered a known exploited vulnerability (KEV)that is being exploited in wild..
While CVE-2024–6387 presents a critical security risk, its real-world impact is mitigated by several factors. The technical complexity of the exploit and the extensive time required to execute it make large-scale attacks impractical. Each attack attempt resets the login timer, requiring precise timing and substantial effort from the attacker.
Moreover, the vulnerability affects specific versions of OpenSSH (up to 4.4p1 and 8.5p1 to 9.7p1) running on Linux systems using the GNU C Library. Systems with additional protections against brute force attacks and distributed denial-of-service (DDoS) are less likely to be successfully exploited. Therefore, while targeted attacks are possible, mass exploitation is unlikely due to the unavailability of working exploits and the time required to exploit these vulnerabilities.
Mitigation
To mitigate the risks associated with CVE-2024–6387, administrators should immediately update OpenSSH to version 9.8 or later. If immediate updating is not feasible, reducing the LoginGraceTime can provide temporary mitigation against this vulnerability.
Additionally, organisations can consider implementing the following best practises for general vulnerability exploit protection:
Patch management
Regularly updating and patching software, operating systems, and applications is the most straightforward method for organisations to avoid the exploitation of vulnerabilities within their systems.
Network segmentation
Separating critical network segments from the larger network can minimise the impact of a potential vulnerability exploitation.
Regular security audits
Performing security audits and vulnerability assessments can identify and remediate potential weaknesses within the infrastructure before they can be exploited.
Security awareness training
Educating employees about the common tactics used by attackers can help them avoid falling victim to social engineering attacks that might precede vulnerability exploitation.
Incident response plan
Developing, testing, and maintaining an incident response plan can help organisations quickly and effectively respond to security breaches and vulnerability exploitations.
Additionally, employing network-based access controls, intrusion prevention systems such as Trend Vision One™, and regular vulnerability scanning can further enhance security.
For Trend customers, the following IPS smart rules can detect the attack on a surface level:
- 1003593 Detected SSH Server Traffic (ATT&CK T1021.004)
- 1005748 Multiple SSH Connection Detected (ATT&CK T1499.002, T1110)
Conclusion
According to other researchers, there could be non-functional exploits in circulation that claim to be working proofs-of-concept (POCs) for CVE-2024-6387. These fake exploits contain payloads that download files from remote servers and establish persistence on the systems of security researchers. Assuming they are testing a legitimate POC for the vulnerability, the security features of their systems might be disabled, making them vulnerable to malicious activities.
Overall, while CVE-2024–6387 and CVE-2024-6409 is a critical vulnerability, it does not pose a widespread threat to the internet due to its exploitation complexity and existing mitigations. However, administrators should remain vigilant, apply patches promptly, and implement recommended security practises to protect their systems.