CVE-2024-6387 – RCE Vulnerability in OpenSSH

Introduction

A high-severity remote code execution (RCE) vulnerability, CVE-2024-6387, has been discovered in OpenSSH’s server by the Qualys research team. This vulnerability is particularly concerning as it revives an issue that was previously addressed in 2006, highlighting the persistence of hidden bugs in widely used secure software. This discovery follows another significant vulnerability in the XZ Utils library found just a few months ago, underscoring ongoing security challenges.

Although CVE-2024- 6387 is a serious flaw, it is notably difficult to exploit, and no successful remote attacks have been reported so far. Nonetheless, it is crucial to understand the risk and take measures to protect your systems, especially given SSH’s extensive use for accessing Kubernetes nodes and sometimes within Kubernetes workloads, thus significantly impacting cloud systems.

The CVSS v3 base score for the vulnerability is 8.1, with a High severity rate.

Dive-In

A signal handler race condition vulnerability was discovered in OpenSSH server (sshd) affecting its default configuration. If an SSH client fails to authenticate within the `LoginGraceTime` period (120 seconds by default), the SIGALRM (signal alarm) handler is called asynchronously. However, some of the functions it calls are not async-signal-safe, including `syslog()`. In glibc-based Linux distros, under certain conditions, `syslog()` calls the async-signal-unsafe functions `malloc()` and `free()`.

If a call to either of these is interrupted by code that also calls a heap-related function, this could lead to heap corruption, which can be exploited to achieve arbitrary code execution with sshd’s root privileges.
According to Cyberint Research, widespread exploitation of this vulnerability is unlikely. Current exploitations rely on distribution-specific conditions (like ASLR) and glibc-version-specific struct layouts, requiring attackers to know the target Linux distribution in advance to build a functional exploit. This significantly limits the vulnerability’s potential for widespread opportunistic exploitation.

Additionally, successful exploitation typically requires several hours of login attempts, resembling a password brute-force attack, which can be mitigated by existing brute-force prevention and detection measures. However, attackers could adopt a more patient approach, targeting machines over several weeks and switching between multiple IP addresses, similar to password spraying, making detection more difficult.

Below is an example from this GitHub repo demonstrating how an attacker might exploit this vulnerability:

The research paper provides practical examples illustrating exploitation in different OpenSSH
versions:

• **OpenSSH 3.4p1 on Debian**: Exploitation involves interrupting a `free()` call with `SIGALRM`
  during public-key parsing, leaving the heap in an inconsistent state, then exploiting another `free()` call inside the `SIGALRM` handler. Around 10,000 attempts are required, typically taking about a week with 10 connections every 600 seconds.
• **OpenSSH 4.2p1 on Ubuntu**: The attack targets a `pam_start()` call with `SIGALRM`, creating an inconsistent state in PAM’s structures, then exploiting during a `pam_end()` call inside the `SIGALRM` handler. Approximately 10,000 attempts are needed, taking around 1-2 days with 10 connections every 120 seconds.
• **OpenSSH 9.2p1 on Debian**: The attack interrupts a `malloc()` call with `SIGALRM` during publickey parsing, leading to heap corruption, then exploiting another `malloc()` call inside `syslog()`. Around 10,000 attempts are required, taking around 6-8 hours due to the need to guess the glibc address correctly about half the time.
  Researchers focused primarily on virtual machines with stable network conditions. While significant
  progress has been made, further improvements are expected, especially for exploiting newer amd64
  systems where ASLR is stronger. A related bug report led to immediate communication with OpenSSH developers, highlighting the need for swift action in addressing such vulnerabilities.

Impact

The following versions of OpenSSH are affected by this vulnerability:

• OpenSSH versions earlier than 4.4p1
• OpenSSH versions between 8.5p1 and 9.8p1 (excluding)

The vulnerability is exploitable on glibc-based Linux distributions (e.g., Debian-based). As of July 1st, 2024, no exploitation has been identified in the wild, with proven exploitation occurring only under lab conditions on 32-bit Linux/glibc systems (with ASLR). Exploitation on 64-bit systems has not been proven but is believed possible.

Recommendations

System administrators should remain vigilant, apply patches promptly, and implement additional safeguards to mitigate the risks posed by such vulnerabilities. By staying informed and proactive, organizations can significantly strengthen their resilience against emerging cybersecurity threats.

Cyberint Recommends to take the following security steps:

• **Update OpenSSH to the Latest Version –
  • ** To address this vulnerability, upgrade to the latest OpenSSH release, which includes the necessary fix. Keeping your OpenSSH installation current is crucial for security and protection against known vulnerabilities.
• **Implementing a Temporary Workaround -** If an upgrade is not immediately possible, mitigate the risk by setting the `LoginGraceTime` parameter to 0 in the OpenSSH configuration file. This prevents unauthenticated sessions from remaining open and being exploited, although it may cause a denial of service if all connection slots become occupied.

References

https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remoteunauthenticated-code-execution-vulnerability-in-openssh-server
https://www.openssh.com/txt/release-9.8
https://github.com/zgzhang/cve-2024-6387-poc
https://www.tenable.com/cve/CVE-2024-638