Examining the Possible Influence of the OpenSSH Vulnerabilities CVE-2024–6387 and CVE-2024-6409

The vulnerability known as “regreSSHion” emerges due to the insecure management of the SIGALRM signal while conducting SSH authentication.

The Potential Impact of the OpenSSH Vulnerabilities CVE-2024–6387 and CVE-2024-6409

The vulnerability known as “regreSSHion” emerges due to the insecure management of the SIGALRM signal while conducting SSH authentication. Upon expiration of the LoginGraceTime, the SIGALRM signal is triggered, and the associated handler executes specific actions, which includes invoking non-async-signal-safe functions like syslog(). This scenario sets the stage for a race condition, where the sequencing of operations may result in memory corruption or other unexpected behaviors.

SIGALRM represents a signal within Unix-like operating systems that signals an alarm or timer runout. Once a process establishes and a function triggers, it arranges for a SIGALRM signal to be dispatched to the process after a designated time interval. Generally, this signal assists in timing operations, such as enforcing timeouts for network requests or scheduling recurring tasks. Processes can define custom signal handlers to address SIGALRM, enabling them to execute actions like terminating processes, resetting timers, or controlling execution time limits. In essence, SIGALRM streamlines time-sensitive operations in Unix processes by delivering a mechanism to manage set alarms and timing events.

To exploit CVE-2024–6387, an attacker must generate numerous connection attempts to accurately trigger the race condition. The method involves repetitively initiating and resetting the LoginGraceTime, prompting the server to trigger the SIGALRM signal handler. This demands precise timing and proper inputs to manipulate the server’s memory configuration, which leads to heap corruption and potential code execution.

Signal handlers are designated functions that are invoked in response to specific signals dispatched to a program. These signals can originate from the operating system or the program itself. Nonetheless, not all functions are safe to invoke within a signal handler as they may lack reentrancy, hence rendering them unsafe for interruption and reinvocation (“async-signal-safe”). For instance, syslog() functions as a tool to record messages to the system logger and isn’t recognized as async-signal-safe.

Research indicates that around 10,000 attempts are necessary to successfully exploit this vulnerability. Although the exploitation process could span days, success is not guaranteed. Modern security features like Address Space Layout Randomization (ASLR) and No-eXecute (NX) bits introduce complexity to the exploitation process but do not fully eliminate the risk.

Similar to CVE-2024-6387, this vulnerability manifests when the SSHD’s SIGALRM handler is invoked asynchronously, thereby triggering various functions that are not considered async-signal-safe.

The race condition in grace_alarm_handler() initiates the execution of cleanup_exit() within the privsep child process. However, cleanup_exit() isn’t structurally designed for activation from a signal handler, potentially leading to the invocation of unsafe functions. Signal interruptions during cleanup function calls can result in precarious state alterations and potential remote code execution (RCE).

Considering a privsep child process operates with reduced privileges, there is lesser concern regarding the vulnerability. Furthermore, functional exploits for the CVE-2024-6409 issue have not been unearthed, thereby lacking clear proof of successful exploitation at the publication time.

The OpenSSH vendor’s advisory denotes that the successful exploitation of CVE-2024-6387 was illustrated on 32-bit Linux and GNU C Library (glibc) systems featuring ASLR. The advisory also implies potential exploitation on 64-bit systems. However, specific attributes of X64 systems render this exploitation substantially more challenging, as detailed below.

In x64 setups, ASLR plays a pivotal part by randomizing memory addresses, encompassing those of the GNU C Library (glibc), with each program activation. This unpredictability complicates attackers’ predictions of the glibc base address, thereby negating exploits reliant on precise memory targeting. The extensive address space of the x64 architecture further complicates exploitation, as attackers confront an exponentially larger pool of potential addresses to guess. When coupled with protective measures like stack canaries and NX bits, exploiting vulnerabilities such as CVE-2024-6387 becomes highly unworkable on x64 systems.

Though feasible under specific conditions, the effective application of ASLR and the intricacies of the x64 environment significantly diminish real-world exploit opportunities, underscoring the resilient security advantages of these structural safeguards.

Based on our internal telemetry, there hasn’t been a noticeable trend shift for CVE-2024–6387, thus categorizing it as a known exploited vulnerability (KEV) that may be under exploitation in the wild. .

Despite CVE-2024–6387 posing a critical security risk, the practical impact is lessened by several factors. The technical intricacy of exploitation and the extensive time investment required render large-scale attacks impracticable. Each attack endeavor resets the login timer, necessitating precise timing and substantial attacker effort.

Furthermore, the vulnerability impacts specific versions of OpenSSH (up to 4.4p1 and 8.5p1 to 9.7p1) on Linux systems utilizing the GNU C Library. Systems fortified against brute force and distributed denial-of-service (DDoS) attacks are less susceptible to exploitation. Hence, though targeted assaults are viable, widespread exploitation is improbable due to the absence of functional exploits and the time-intensive nature of exploiting these vulnerabilities.

Mitigation

To mitigate the risks stemming from CVE-2024–6387, administrators should promptly update OpenSSH to version 9.8 or above. Alternatively, reducing the LoginGraceTime can serve as a temporary countermeasure against this vulnerability.

Additionally, organizations might contemplate implementing the subsequent best practices to bolster general safeguarding against vulnerability exploitation:

Patch management
Regularly maintaining and patching software, operating systems, and applications remains the most direct route for organizations to avert vulnerability exploits within their systems.

Network segmentation
Segmenting essential network sections from the broader network can minimize potential vulnerabilities exploitation impacts.

Regular security audits
Executing security audits and vulnerability assessments can uncover and address likely weaknesses within the infrastructure before they turn exploitable.

Security awareness training
Educating employees on prevalent attacker tactics can heighten their competence in evading social engineering attempts that often precede vulnerability exploits.

Incident response plan
Formulating, validating, and maintaining an incident response strategy can empower organizations to swiftly and efficiently counter security breaches and vulnerability exploitations.

Additionally, deploying network-centric access controls, intrusion prevention mechanisms like Trend Cloud One™, and routine vulnerability scanning can further fortify security.
For Trend clients, the subsequent IPS smart rules can detect preliminary attack signs:

  • 1003593 Detected SSH Server Traffic (ATT&CK T1021.004)
  • 1005748 Multiple SSH Connection Detected (ATT&CK T1499.002, T1110)

According to alternative researchers, there might be non-functional exploits circulating as alleged proofs-of-concept (POCs) for CVE-2024-6387. These counterfeit exploits harbor payloads that fetch materials from remote servers and secure persistence on the systems of security researchers. If the researchers falsely presume they are experimenting with a bona fide POC for the vulnerability, their systems’ security features could be disabled, rendering them susceptible to hostile activities.

Ultimately, while CVE-2024–6387 and CVE-2024-6409 stand as critical vulnerabilities, they don’t represent a pervasive internet threat due to the intricacies involved in exploitation and the present mitigations. Nevertheless, administrators must maintain vigilance, apply patches promptly, and integrate the suggested security practices to safeguard their systems.

About Author

Subscribe To InfoSec Today News

You have successfully subscribed to the newsletter

There was an error while trying to send your request. Please try again.

World Wide Crypto will use the information you provide on this form to be in touch with you and to provide updates and marketing.