Introduction
On July 1st 2024, Qualys research disclosed a vulnerability they've called regreSSHion in the popular OpenSSH server software. This vulnerability, if properly exploited, could result in pre-authentication remote code execution on the affected host. Secure Shell (SSH)is a service that is commonly exposed to the internet, so it's important to understand the severity and likelihood of exploitation.
Key points and observations:
- Jul 1, 2024: Public disclosure of the vulnerability by Qualys team along with a technical technical advisory.
- Jul 1, 2024: OpenSSH released v9.8/9.8p1 to patch the vulnerability.
- The vulnerability was re-introduced as a regression from a vulnerability patched in 2006, CVE-2006-5051.
- Exploit conditions involve a complex race condition and the Qualys team reproduced it only on x86 systems with upwards of 10,000 connection retries and which ranged from several hours to one week.
- Datadog Security Research assesses that due to exploit conditions, which include architecture complications, modern exploit prevention techniques like ASLR, and the speed of the exploit, exploitation is difficult for attackers to weaponize at scale. However, we want to emphasize that motivated attackers targeting specific organizations will likely spend a week to exploit a vulnerable target.
Check if your system is vulnerable
According to Qualys the following versions of OpenSSH are vulnerable:
- OpenSSH < 4.4p1 (If not patched for CVE-2006-5051 and CVE-2008-4109)
- 8.5p1 <= OpenSSH < 9.8p1
- Ubuntu 24.04 is not vulnerable due to ASLR configuration
- OpenBSD is not vulnerable because it uses a safer version of
syslog()introduced in 2001
To manually determine if your SSHD systems are running the affected version you can use the following shell command:
sshd -V
Remediate affected systems
To remediate the vulnerable OpenSSH simply upgrade it to the latest version published by OpenSSH today (9.8/9.8p1).
If you can’t upgrade for any reason you can set the loginGraceTime to 0 in your configuration file this will make it safe against the remote code execution technique in this CVE. However, as noted by Qualys researchers, this setting can lead to a potential denial of service.
Phased approach
For most organizations, we recommend a phased approach where the first phase includes identification and remediation of public facing SSH services, and the second phase extends the effort to non-public facing instances of SSH.
Details and analysis
The vulnerability is a race condition in OpenSSH server (sshd) where the SIGALRM handler is called asynchronously but calls other functions which are not async-signal-safe like syslog().
It’s worth noting that this vulnerability is a regression of CVE-2006-5051 which was reported in 2006, but the patch was accidentally removed in version 8.5p1.
The idea behind the exploit is to not authenticate a client within the loginGraceTime (120 by default, 600 in older versions of OpenSSH) then sshd SIGALRM handler will be invoked asynchronously and it will invoke syslog() which calls async-signal-unsafe functions like malloc() and free().
In the research presented by Qualys,they interrupted the call to malloc() with SIGALRM (inside the sshd’s public-key parsing code) and exploited the inconsistent state of the heap during another call to malloc() inside the syslog() function.
Exploitability
It's important to highlight that although this vulnerability is critical and needs to be patched as soon as possible, the exploitation is not trivial and our assessment that it will be difficult for attackers to weaponize this exploit at scale. However, we want to emphasize that motivated attackers targeting specific organizations will likely spend a week to exploit a vulnerable target.
According to the Qualys Research Team it takes ~10,000 tries on average to achieve the race condition. Depending on the number of connections and the loginGraceTime it can take anywhere from 6 hours to a week to obtain remote code execution.
Additionally, the research was completed on 32bit systems, exploiting the vulnerability on amd64 is significantly harder because of the stronger implementation of ASLR.
How Datadog can help
Datadog Cloud Security Management (CSM) customers can use CSM Vulnerabilities to identify any virtual machine or container that is vulnerable, using the query status:Open cve:CVE-2024-6387 is_publicly_accessible:"Accessible" direct link.
We suggest that FIRST, you run this query and update/address any public facing SSH services. Then, we recommend going back and addressing the rest of the vulnerable ssh services that are only accessible internally.
Hovering your mouse over any affected virtual machine or container allows you to benefit from additional context such as the cloud account it's running in, operating system and misconfigurations that may affect it. It also enables you to easily pivot to observability data such as logs or network connections.
Datadog Security Research Team is actively monitoring this vulnerability and exploitation. Refer to our Research Feed for further information.
Conclusion
CVE-2024-6387 presents a significant security risk, as it allows unauthenticated users to obtain a root shell on vulnerable systems. We recommend upgrading to non-vulnerable versions of OpenSSH server as soon as possible.
We hope that the details provided in this blog post will help security practitioners better understand, detect, and mitigate this threat.
