The Qualys Threat Research Unit (TRU) has warned that an OpenSSH vulnerability it has named regreSSHion could be another Log4J. The National Vulnerability Database (NVD) has listed it as CVE-2024-6387 and assigned it an 8.5 score. While not critical, this is a high score that demands attention. Qualys claims it has detected over 14 million potentially vulnerable OpenSSH server instances using Censys and Shodan.
Bharat Jogi, Senior Director, Threat Research Unit, Qualys, wrote, “This vulnerability is a regression of the previously patched vulnerability CVE-2006-5051, which was reported in 2006. A regression in this context means that a flaw, once fixed, has reappeared in a subsequent software release, typically due to changes or updates that inadvertently reintroduce the issue.
“This incident highlights the crucial role of thorough regression testing to prevent the reintroduction of known vulnerabilities into the environment. This regression was introduced in October 2020 (OpenSSH 8.5p1).”
What is regreSSHion?
The TRU describes regreSSHion as a signal handler race condition in OpenSSH’s server. Any SSH service accessed over the Internet is vulnerable. An attacker does not need any privileges on a target system. The vulnerability allows an attacker to execute code on a glibc-based Linux system remotely. That code is executed as root, giving it the highest privilege level.
Such an attack has several potential consequences. An attacker could take control of a system, install backdoors, steal data or execute malware. They could also use it as an entrance point into an organisation. Moving laterally from the server to attack and control other systems.
To prove the risk that regreSSHion poses, Qualys developed a proof of concept (PoC) on both Intel and AMD architectures. However, it has clarified that it will not make that PoC public.
What systems are affected, and how to mitigate
Qualys has listed all the versions of OpenSSH that it claims are vulnerable to regreSSHion. They are:
- OpenSSH versions earlier than 4.4p1 are vulnerable to this signal handler race condition unless they are patched for CVE-2006-5051 and CVE-2008-4109.
- Versions from 4.4p1 up to, but not including, 8.5p1 are not vulnerable due to a transformative patch for CVE-2006-5051, which made a previously unsafe function secure.
- The vulnerability resurfaces in versions from 8.5p1 up to, but not including, 9.8p1 due to the accidental removal of a critical component in a function.
- OpenBSD systems are unaffected by this bug, as OpenBSD developed a secure mechanism in 2001 that prevents this vulnerability.
Meanwhile, Linux distributors are all issuing patches to mitigate the effects of regreSSHion, and those patches should be applied immediately. However, for many customers, patching might not be as simple as it sounds.
Qualys has said that those unable to patch immediately should limit SSH access through network controls to minimize risk. It also recommends that organisations review and implement network segmentation and alerts from their intrusion detection systems.
As a final suggestion, it also says, “If sshd can’t be updated or recompiled, set LoginGraceTime to 0 in the config file. This exposes sshd to a denial of service by using up all MaxStartups connections, but it prevents the remote code execution risk.”
Enterprise Times: What does this mean?
Is this another Log4J? Who knows? While the number of potentially affected systems is large, how many will be affected is unknown. We do know that even with all the responses from vendors and the security industry, there will be unpatched systems for some time.
Importantly, Qualys has called for better regression testing for security patches. One flaw in many regression tests is the belief that some code is so trusted that it doesn’t need to be retested. That view has been around for many years and is unlikely to go away as testing times continue to get squeezed. However, as this incident shows, NO code should be considered protected.
However, Qualys is not attacking OpenSSH. It said, “OpenSSH stands as a benchmark in software security, exemplifying a robust defence-in-depth approach. Despite the recent vulnerability, its overall track record remains exceptionally strong, serving as both a model and an inspiration in the field.”
