On July 1, 2024, OpenSSH released fixes for CVE-2024-6387, a vulnerability in OpenSSH’s server (sshd) on glibc-based Linux systems allowing for potential Remote Code Execution (RCE). OpenSSH is a widely-used suite of secure networking tools based on the SSH protocol, providing encryption for secure communication and file transfers, and is essential for remote management on Unix systems.
CVE-2024-6387 is a signal handler race condition that allows unauthenticated Remote Code Execution (RCE) as root. This could enable threat actors to install malware, manipulate data, or create persistent backdoors upon compromising the system. The vulnerability is a regression emerging from a previously patched issue (CVE-2006-5051).
Importantly, CVE-2024-6387 was found to be highly complex to exploit, as detailed in Qualys’ findings. According to their technical analysis, the attack typically demands 6 to 8 hours of continuous connections, up to the server’s maximum capacity. This vulnerability requires knowledge of the target’s Linux distribution due to factors specific to each distribution, such as Address Space Layout Randomization (ASLR) and glibc configurations. Furthermore, to date, only 32-bit systems have been demonstrated to be exploitable, though exploitation on 64-bit systems is expected to be possible. As of now, there have been no reported instances of this vulnerability being exploited in the wild, according CISA’s Known Exploited Vulnerabilities Catalog and available threat intelligence.
Despite the low likelihood of exploitation, Arctic Wolf still recommends upgrading to the latest version of OpenSSH during your organization’s normal patching cycle.
Recommendation for CVE-2024-6387
Upgrade Distribution-Specific OpenSSH Packages
Arctic Wolf recommends following the guidance provided by Linux distribution vendors as shown in the table below:
| Linux Distribution | Version | Affected? | Recommendation |
| Red Hat Enterprise Linux | RHEL 6 | No | No action required. |
| RHEL 7 | No | No action required. | |
| RHEL 8 | No | No action required. | |
| RHEL 9 | Yes | Apply LoginGraceTime mitigation. No updated OpenSSH package available yet. | |
| Fedora | Fedora 33 and earlier | No | No action required. |
| Fedora 34 to 40 | Yes | No distribution-specific advisory available.
Apply LoginGraceTime mitigation documented in workarounds section, and upgrade the package once openssh version 9.8 becomes available. |
|
| Fedora 34 to 40 | Yes | No distribution-specific advisory available.
Apply LoginGraceTime mitigation documented in workarounds section, and upgrade the package once openssh version 9.8 becomes available. |
|
| Debian | Bullseye | No | No action required. |
| Bookworm | Yes | Upgrade openssh package to 1:9.2p1-2+deb12u3, using the security repository. | |
| Sid | No | No action required. | |
| Trixie | No | No action required. | |
| openSUSE | Leap 15.5 and earlier | No | No action required. |
| Leap 15.6 | Yes | No distribution-specific advisory available.
Apply LoginGraceTime mitigation documented in workarounds section, and upgrade the package once openssh version 9.8 becomes available. |
|
| Alpine | Versions 3.13 and earlier | No | No action required. |
| Versions 3.14 to 3.20 | Yes | No distribution-specific advisory available.
Apply LoginGraceTime mitigation documented in workarounds section, and upgrade the package once openssh version 9.8 becomes available. |
|
| Arch Linux | All | Yes | Upgrade to openssh package version 9.8p1-1 or later. |
| Other Linux distributions not listed above | Other Linux distributions not listed above bundling OpenSSH 8.5p1 onwards, but excluding 9.8p1. | Yes | Arctic Wolf recommends that users upgrade to openssh version 9.8 using native package management wherever possible.
If an upgraded package is not available, apply the LoginGraceTime mitigation documented in workarounds section. |
| Other Linux distributions not listed above bundling OpenSSH versions earlier than 4.4p1 (if not backport-patched against CVE-2006-5051, or not patched against CVE-2008-4109). | Yes | Arctic Wolf recommends that users upgrade to openssh version 9.8 using native package management wherever possible.
If an upgraded package is not available, apply the LoginGraceTime mitigation documented in workarounds section. |
Please follow your organization’s patching and testing guidelines to avoid operational impact.
Workarounds
Set LoginGraceTime to 0
According to Qualys, if ssh cannot be updated, the signal handler race condition can be fixed by setting LoginGraceTime to 0 in /etc/ssh/sshd_config. Note that this makes sshd potentially vulnerable to a denial of service attack (the exhaustion of all MaxStartups connections), but mitigates the remote code execution vulnerability presented in this security bulletin.
Implement Blocking Solution Such as Fail2ban or Firewall Blocklists
As a security configuration best practice, blocking solutions such as fail2ban or firewall blocklists can be implemented to prevent common offenders from accessing your assets running ssh. This minimizes the attack surface for vulnerabilities such as CVE-2024-6387.
Please note that blocking solutions may adversely impact availability if misconfigured. Please follow your organization’s patching and testing guidelines to avoid operational impact.
References
