{"id":56596,"date":"2024-07-17T00:00:00","date_gmt":"2024-07-17T00:00:00","guid":{"rendered":"urn:uuid:3e510beb-3725-3f44-bc94-914ef254ca78"},"modified":"2024-07-17T00:00:00","modified_gmt":"2024-07-17T00:00:00","slug":"the-potential-impact-of-the-openssh-vulnerabilities-cve-2024-6387-and-cve-2024-6409","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/the-potential-impact-of-the-openssh-vulnerabilities-cve-2024-6387-and-cve-2024-6409\/","title":{"rendered":"The Potential Impact of the OpenSSH Vulnerabilities CVE-2024\u20136387 and CVE-2024-6409"},"content":{"rendered":"

<\/p>\n

<\/div>\n

The \u201cregreSSHion\u201d vulnerability arises from the unsafe handling of the SIGALRM<\/i> signal during SSH authentication. When the LoginGraceTime<\/i> expires, the SIGALRM<\/i> signal is raised, and the corresponding handler performs certain actions, including calling non-async-signal-safe functions like syslog().<\/i> This can create a race condition, where the timing of operations could lead to memory corruption or other unexpected behaviors.<\/p>\n

<\/span>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.<\/i><\/span><\/p>\n

Exploiting CVE-2024\u20136387 requires an attacker to initiate thousands of connection attempts to trigger the race condition accurately. The process involves repeatedly setting and resetting LoginGraceTime<\/i>, causing the server to invoke the SIGALRM<\/i> signal handler. This requires precise timing and proper inputs to manipulate the server\u2019s memory layout, leading to heap corruption and code execution.<\/p>\n

<\/span>Signal handlers are special functions that get called in response to specific signals sent to a program. These signals can be generated, either by the operating system or by the program 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 (\u201casync-signal-safe\u201d). For instance, syslog() is a function used to log messages to the system logger and is not considered async-signal-safe.<\/i><\/span><\/p>\n

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.<\/p>\n

Like CVE-2024-6387, this vulnerability occurs when the SSHD\u2019s SIGALRM<\/i> handler is called asynchronously, which in turn calls various functions that are not async-signal-safe<\/i>.<\/p>\n

The race condition in grace_alarm_handler()<\/i> calls cleanup_exit()<\/i> from the privsep<\/i> child process. However, cleanup_exit()<\/i> 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).<\/p>\n

As a privsep<\/i> child process run\u2019s 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.<\/p>\n

The OpenSSH vendor advisory<\/a> mentions that the successful exploitation of CVE-2024-6387 has been demonstrated on 32-bit Linux and GNU C Library (glibc<\/i>) 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\u2019ll expound on in this section.<\/p>\n

In x64 systems, ASLR plays a crucial role by randomizing memory addresses, including those of the GNU C Library (glibc<\/i>), with each program execution. This randomness makes it very difficult for attackers to predict the location of the glibc<\/i> 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.<\/p>\n

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.<\/p>\n

Our As per our internal telemetry we did not notice any trend change for CVE-2024\u20136387, which could be considered a known exploited vulnerability (KEV)that is being exploited in wild. .<\/p>\n

While CVE-2024\u20136387 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.<\/p>\n

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<\/i><\/b> due to the unavailability of working exploits and the time required to exploit these vulnerabilities.<\/p>\n

Mitigation<\/span><\/p>\n

To mitigate the risks associated with CVE-2024\u20136387, administrators should immediately update OpenSSH to version 9.8 or later. If immediate updating is not feasible, reducing the LoginGraceTime<\/i> can provide temporary mitigation against this vulnerability.<\/p>\n

Additionally, organizations can consider implementing the following best practices for general vulnerability exploit protection:<\/p>\n

Patch management
<\/b>Regularly updating and patching software, operating systems, and applications is the most straightforward method for organizations to avoid the exploitation of vulnerabilities within their systems.<\/b><\/p>\n

Network segmentation<\/b>
Separating critical network segments from the larger network can minimize the impact of a potential vulnerability exploitation.<\/p>\n

Regular security audits<\/b>
Performing security audits and vulnerability assessments can identify and remediate potential weaknesses within the infrastructure before they can be exploited.<\/p>\n

Security awareness training<\/b>
Educating employees about the common tactics used by attackers can help them avoid falling victim to social engineering attacks that might precede vulnerability exploitation.<\/p>\n

Incident response plan<\/b>
Developing, testing, and maintaining an incident response plan can help organizations quickly and effectively respond to security breaches and vulnerability exploitations.<\/p>\n

Additionally, employing network-based access controls, intrusion prevention systems such as Trend Cloud One\u2122<\/a>, and regular vulnerability scanning can further enhance security.
For Trend customers, the following IPS smart rules can detect the attack on a surface level:<\/p>\n