Introduction
On July 2, 2024, a vulnerability identified as CVE-2024-6387 was discovered in OpenSSH. This vulnerability is a race condition found in the SSH server (sshd). When a user fails to authenticate within the default 120 seconds (previously 600 seconds, known as LoginGraceTime), the SIGALRM handler of sshd is called asynchronously. However, this signal handler calls multiple functions that are not asynchronous-signal-safe, such as syslog(). An attacker exploiting this vulnerability could potentially achieve remote code execution (RCE) with root privileges.
Affected Versions
- OpenSSH < 4.4p1
- 8.5p1 ≤ OpenSSH < 9.8p1
Ubuntu’s Remediation Approach
For systems with Ubuntu Pro enabled, the SSH package has already been updated and patched:
|
|
Although the SSH version shown is OpenSSH 9.6p1, it includes the necessary patch. Therefore, no further upgrade of SSH is required.
The original OpenSSH 9.6p version remains in use due to compatibility issues preventing a complete upgrade. Instead, modifications and testing were performed on this version to patch the vulnerability. After fixing the vulnerability, a patch was created using Git’s format-patch and applied during the compilation process. This method is common in software compilation.
The Ubuntu-maintained OpenSSH repository shows commit 19e460, which includes the CVE-2024-6387.patch. This patch modifies the sshsigdie function in log.c to execute _exit(1) directly without calling sshlogv for logging, thereby avoiding potential security vulnerabilities caused by race conditions.
|
|
Conclusion
As of July 2, 2024, Ubuntu has released patches for this vulnerability in the Jammy (22.04), Mantic (23.10), and Noble (24.04) versions. For systems that have not yet received this patch, according to the current preliminary solution provided by Ubuntu, the vulnerability can be mitigated by setting LoginGraceTime
to 0 in /etc/ssh/sshd_config
. However, this might cause other issues, such as denial-of-service (DoS) attacks.
The vulnerability has currently been demonstrated on 32-bit Linux/glibc systems, with exploitation taking an average of 6-8 hours to reach the maximum number of connections the server will accept. Although it has not yet been successfully demonstrated on 64-bit systems, it is likely that these attacks will be improved in the future, potentially leading to successful exploits. Additionally, the exploitability on Windows and macOS remains unclear at this time.
Most users can simply update their systems via the package manager when the official update is released.