CVE-2024-6387:

OpenSSH sshd has a race condition in signal handling that can allow a remote, unauthenticated attacker to trigger remote code execution or denial of service by timing out during authentication. The vulnerability affects OpenSSH 8.5p1 through 9.7p1; patches are available in OpenSSH 9.8 and later, with vendor advisories (e.g., Red Hat RHSA entries) addressing the issue.

Score
A numerical rating that indicates how dangerous this vulnerability is.

8.1High

Published Date:Jul 1, 2024
CISA KEV Date:*No Data*
Industries Affected:20

Threat Predictions

EPSS Score:48.1
EPSS Percentile:98%

Exploitability

Score:2.2
Attack Vector:NETWORK
Attack Complexity:HIGH
Privileges Required:NONE
User Interaction:NONE
Scope:UNCHANGED

Impact

Score:5.9
Confidentiality Impact:HIGH
Integrity Impact:HIGH
Availability Impact:HIGH

Description Preview

Overview

The OpenSSH vulnerability CVE-2024-6387 centers on a race condition in sshd’s signal handling that can be exploited by a remote attacker who does not authenticate within the allotted timeout. This regression potentially enables remote code execution or denial of service, and it affects OpenSSH server releases up to version 9.7p1 (covering 8.5p1 onward). A patched version is available in OpenSSH 9.8 and newer, and multiple vendor advisories have been issued to address the issue across affected Red Hat products and related ecosystems. Given its network-based exploit path and high impact, applying the official patch is strongly recommended, with mitigations in place only as temporary or partial protections.

Remediation

Upgrade OpenSSH to a patched version (OpenSSH 9.8 or later). For Red Hat and similar ecosystems, apply the vendor advisories and update the openssh packages:
Install or refresh updates corresponding to RHSA-2024:4312, RHSA-2024:4340, RHSA-2024:4389, RHSA-2024:4469, RHSA-2024:4474, RHSA-2024:4479, and RHSA-2024:4484.
Verify the installed version after patching (e.g., rpm -q openssh openssh-server or appropriate package manager) and ensure sshd is restarted.
If immediate upgrading is not feasible, implement a mitigation (not a replacement for patching) and plan a rapid upgrade:
Add or set LoginGraceTime to 0 in /etc/ssh/sshd_config to limit authentication timeout risk.
Restart sshd after changes (e.g., systemctl restart sshd).
Complement with network-side protections: restrict SSH access to trusted IPs, enable firewall rules, and deploy fail2ban or equivalent to monitor and block repeated failed attempts.
Note: Disabling LoginGraceTime or relying on mitigations may reduce exposure but does not fix the underlying race condition; use these only as a temporary measure and remove them once patched versions are deployed.
For non-patchable environments (containers, images, or offline systems), rebuild or replace images with patched OpenSSH versions and re-deploy.
Validate remediation by confirming the system is running a patched OpenSSH version and performing a basic SSH connection test from a trusted client. Consider running a security scan or vulnerability assessment to verify that the CVE is addressed on affected hosts.