Overview
CVE-2024-6387, known as regreSSHion, is a critical vulnerability identified in the OpenSSH server. This flaw allows remote unauthenticated attackers to execute arbitrary code on the target server, posing a severe risk to systems using OpenSSH for secure communications.
Similar to last July’s CVE-2023-38408 affecting OpenSSH, this vulnerability is causing significant concern within the cybersecurity community.
What is CVE-2024-6387?
CVE-2024-6387, dubbed regreSSHion, is a critical unauthenticated remote code execution vulnerability in the OpenSSH server on glibc-based Linux systems. Discovered by Qualys security researchers, this flaw is due to improper input validation in OpenSSH’s handling of certain SSH connections.
Specifically, the vulnerability is caused by a buffer overflow that occurs when an attacker sends a specially crafted request to the OpenSSH server. This overflow allows arbitrary code execution by exploiting how OpenSSH processes user-controlled data during the SSH handshake, failing to validate the length of certain inputs properly.
Does CVE-2024-6387 Affect Me?
To determine if your systems are affected by CVE-2024-6387, evaluate your use of OpenSSH. This vulnerability impacts OpenSSH server versions prior to the latest patch.
- Vulnerable OpenSSH versions:
- Versions earlier than 4.4p1 (unless patched for CVE-2006-5051 and CVE-2008-4109)
- Versions from 8.5p1 up to, but not including, 9.8p1 due to the accidental removal of a critical component
OpenBSD systems are unaffected, as they developed a secure mechanism in 2001 that prevents this vulnerability.
Systems running affected versions of OpenSSH, especially those with publicly accessible SSH servers, are at significant risk. If your OpenSSH deployment is exposed to untrusted networks or the internet, assess the version in use and take immediate action to mitigate the risk.
Has CVE-2024-6387 Been Actively Exploited in the Wild?
As of the latest reports, there have been no confirmed instances of active exploitation of CVE-2024-6387 in the wild. However, due to the widespread use of OpenSSH and the nature of this vulnerability, the risk of exploitation remains high. Cybersecurity experts urge immediate action to mitigate this risk.
Observations from the Field
The Qualys research team emphasized that this vulnerability could be exploited without any prior authentication, making it a severe threat to systems with public-facing SSH servers. The potential impact includes unauthorized remote code execution, leading to complete system compromise, data breaches, and other malicious activities.
Although there are no confirmed exploitation cases, the cybersecurity community remains on high alert. The ease of exploitation and the critical role of OpenSSH in secure communications necessitate proactive measures to protect affected systems. Researchers and security professionals continue to monitor for any signs of active exploitation.
How to Fix CVE-2024-6387
Upgrade OpenSSH
Customers are advised to upgrade to OpenSSH 9.8 or later to remediate this vulnerability. This update addresses the input validation flaw, ensuring that specially crafted requests cannot exploit the vulnerability.
Details of the Fix
On June 6, 2024, the signal handler race condition was fixed by commit 81c1099 (“Add a facility to sshd(8) to penalize particular problematic client behaviors”). This fix moved the async-signal-unsafe code from sshd’s SIGALRM handler to sshd’s listener process, where it can be handled synchronously.
Backporting the Fix
Since this fix is part of a large commit (81c1099), on top of an even larger defense-in-depth commit (03e3de4, “Start the process of splitting sshd into separate binaries”), backporting might be challenging. If backporting is not feasible, the signal handler race condition itself can be fixed by removing or commenting out the async-signal-unsafe code from the sshsigdie()
function.
Additional Recommendations by Qualys
- Restrict Access: Limit SSH access to trusted networks and users only. Implement network access controls to restrict who can connect to your SSH servers.
- Use Strong Authentication: Enhance security by using key-based authentication and disabling password-based logins where possible.
- Monitor and Audit: Regularly monitor SSH access logs for unusual activity and audit your SSH configuration to ensure it follows security best practices.
Alternative Mitigation
If updating or recompiling sshd
is not possible, the signal handler race condition can be mitigated by setting LoginGraceTime
to 0 in the configuration file. While this makes sshd
vulnerable to a denial of service (exhaustion of all MaxStartups connections), it protects against the remote code execution vulnerability presented in this advisory.