Critical Vulnerability in OpenSSH (CVE-2024-6387)
Executive Summary
On July 1st, Qualys Security publicly disclosed details regarding an impactful vulnerability in OpenSSH, an essential software tool used globally for secure network communications and remote system administration. OpenSSH is integral to maintaining confidentiality and control over remote sessions, underpinning a vast array of critical infrastructure across the internet.
The identified vulnerability, tracked as CVE-2024-6387, originates from a regression reintroducing a previously patched flaw (CVE-2006-5051). This vulnerability enables unauthenticated remote attackers to gain root (administrative) access on affected systems. Such access allows attackers to use the compromised device as a springboard for further intrusions into networked systems. Exploitation of this vulnerability is currently non-trivial, requiring thousands of SSH authentication attempts in order to enable successful exploitation of the vulnerability. This method of attack is relatively noisy and can be detected by vigilant monitoring of SSH logs for unusual authentication patterns. The exploitation process varies by system architecture, taking approximately 6-8 hours on 32-bit systems due to fewer memory safety mechanisms compared to 64-bit systems, where exploitation is expected to take significantly longer. Qualys’s threat research team has successfully demonstrated this exploit on 32-bit systems and anticipates that similar timing techniques could potentially compromise 64-bit architectures, although this is expected to be more challenging and time-consuming. Given the severity and the public release of the vulnerability details, there is a high likelihood that threat actors will attempt to weaponize this vulnerability. It is crucial for organizations, especially those running vulnerable 32-bit systems, to monitor for signs of exploitation actively and apply available patches as soon as possible.
Update (2024-07-10 17:00 UTC) – A security researcher at Openwall has reported a separate but similar vulnerability also in OpenSSH that is exploited in the same way. It is being tracked as CVE-2024-6409 and is reported to affect Red Hat Enterprise Linux 9.
Beazley Security would like to note that successfully exploiting this vulnerability requires attackers to tailor their exploit attempts to the specific operating system and OpenSSH version in use by the target system. This requirement for customization, coupled with the diversity of configurations in use, makes mass exploitation of this vulnerability impractical. However, targeted exploitation by sophisticated or motivated attackers is possible.
Beazley Security advises swift action to apply the necessary patches released for affected systems and to enhance monitoring of SSH traffic for signs indicative of the race condition exploit attempt, particularly multiple failed login attempts from the same or recurring IP addresses.
Affected Systems / Products
OpenSSH is integral in various Unix and Linux distributions commonly deployed on servers and network devices that allow remote management via Secure Shell (SSH).
The vulnerability affects the following OpenSSH versions on most major Linux distributions:
- OpenSSH versions Up to 4.4p1 (legacy software)
- OpenSSH versions from 8.5p1 up to before 9.8p1
Update (2024-07-10 17:00 UTC) – CVE-2024-6409, a similar vulnerability affects the following Linux distribution:
- Red Hat Enterprise Linux 9
Note: OpenBSD based systems are unaffected by this bug, as OpenBSD leverages libraries developed with security mechanisms that prevent these types of vulnerabilities.
Mitigations / Workarounds
This vulnerability is exposed through SSH services, and typical security best practices will help as a temporary mitigation:
- Supporting software such as fail2ban that automatically block IPs after repeated failed logins
- Limiting external SSH access to a whitelist of approved hosts
- Strict internal network segmentation of externally exposed servers to limit lateral movement
- Robust network and system log monitoring and alerting system
Qualys also published the following mitigation recommendation on their writeup: set LoginGraceTime to 0 in the config file. This exposes sshd to a denial of service by using up all MaxStartups connections, but it prevents the remote code execution risk. As is common with most workarounds, this step is not ideal, and the officially published patches should be applied as soon as possible.
Patches
The OpenSSH development team resolved this vulnerability on June 6th, 2024. Patches are now available for most major Linux distributions. Organizations are urged to install at least version 9.8p1 of OpenSSH as soon as possible.
Update (2024-07-10 17:00 UTC) – CVE-2024-6409, a similar vulnerability was reported on 2024-07-08 affects Red Hat Enterprise Linux 9 and has been patched by the vendor via RHSA-2024:4457.
Technical Details
The Qualys Threat Research Unit published details of the vulnerability in a technical advisory here.
The vulnerability identified as CVE-2024-6387, involves a sophisticated race condition occurring during the authentication phase when connecting to an OpenSSH server. This race condition arises when the server processes an authentication attempt that is maliciously crafted by an attacker. The vulnerability leverages an instability within the server’s handling of asynchronous signals during the public key authentication.
A race condition, in this context, refers to the behavior of an application where the outcome is dependent on the sequence or timing of uncontrollable events such as signals and other processes. When the OpenSSH server processes the attacker’s authentication attempt, it triggers a condition where the memory operations performed by the server (such as allocate and deallocate memory) are not synchronized with the incoming signals, thereby “destabilizing” the allocated memory on the impacted the server.
The exploitation of this vulnerability is highly technical and complex, requiring the attacker to meticulously send multiple, often thousands, of SSH authentication requests that have been maliciously crafted. According to Qualys, even after optimizing their approach, it required around 10,000 attempts, typically spanning six to eight hours, to successfully exploit the vulnerability and gain a remote root shell on 32-bit systems.
This high number of required attempts translates into a detectable footprint within network and server logs. The multiple failed authentication attempts are logged, creating what is known as “noise” that can be monitored by security teams.
This level of noise can serve as a detectable warning for security teams who monitor system logs and network traffic, enabling early detection of an exploitation attempt. Security teams should look for anomalies in SSH authentication traffic and alerts of repeated failures from the same IP address or range of addresses, which could indicate an ongoing attack exploiting this race condition.
How Beazley Security is Responding
Beazley Security is monitoring client perimeter devices discovered by our Attack Surface Management Solution, Karma, to identify potentially impacted devices and support organizations in remediation of any issues found.
Sources
Aware of an incident impacting your industry? Let us know: