Researchers have identified a significant remote code execution (RCE) vulnerability that could affect millions of OpenSSH servers. The vulnerability – dubbed ‘regreSSHion’ and recorded as CVE-2024-6387 – allows for unauthenticated root-level remote code execution, posing a serious security risk.
The vulnerability affects OpenSSH server software running on Linux systems that use the GNU C Library. It stems from a race condition in how OpenSSH handles certain signals during connection attempts.
regreSSHion Vulnerability and Its Impact
Researchers from Qualys discovered that the vulnerability stems from a signal handler race condition in OpenSSH’s server (sshd) on glibc-based Linux systems. The vulnerability is remotely exploitable, making it a significant threat to Linux systems.
The potential impact of this vulnerability is severe, as it could lead to a complete system takeover, installation of malware, data manipulation, and the creation of backdoors for persistent access. An attacker with root access could bypass critical security mechanisms such as firewalls, intrusion detection systems, and logging mechanisms, making it even more challenging to detect and respond to an attack.
The regreSSHion vulnerability impacts a broad range of OpenSSH versions, from the earliest releases up to, but not including, version 9.8p1. However, its effects vary depending upon the version:
- Versions before 4.4p1 are vulnerable unless patched for earlier, related flaws.
- Versions 4.4p1 to 8.5p1 are not affected due to previous security fixes.
- Versions 8.5p1 to 9.8p1 are vulnerable due to an accidental removal of critical code.
However, servers on OpenBSD systems remain unaffected thanks to a secure mechanism implemented in 2001. The researchers stated that they had developed a working exploit for the vulnerability and had disclosed it to the OpenSSH team to assist in remediation efforts. While the researchers do not release exploits as part of firm policy, they believe that other researchers would be able to replicate results.
Mitigating Risk to OpenSSH Servers
The vulnerability’s discovery highlights the importance of ongoing security audits and regression testing in software development. The flaw is a reintroduction of a bug first patched in 2006, demonstrating how even well-maintained projects can inadvertently reopen old security holes.
Organizations running vulnerable OpenSSH versions should take immediate action:
- Apply patches: Update to OpenSSH 9.8p1 or apply vendor-provided fixes for older versions.
- Limit access: Restrict SSH connections through network controls to reduce attack surface.
- Segment networks: Isolate critical systems to prevent lateral movement if a breach occurs.
- Monitor activity: Deploy intrusion detection systems to alert on potential exploitation attempts.
- Assess exposure: Use asset management tools to identify vulnerable systems across the enterprise
For systems that can’t be immediately patched, the researchers recommend setting the LoginGraceTime parameter to 0 in the SSH configuration file as a way to mitigate against remote-code execution. However, the researchers warn that this could instead leave the server vulnerable to denial-of-service attacks.
