Researchers at cybersecurity software provider Qualys Inc. are warning of an OpenSSH vulnerability affecting more than 14 million servers that some security researchers are calling “extremely dangerous” and “about as bad as they come.”
The vulnerability, tracked as CVE-2024-6387 and dubbed “regreSSHion,” is a remote unauthenticated code execution vulnerability in OpenSSH’s server in glibc-based server systems. OpenSSH’s server is a secure network utility that provides encrypted communication for remote server management and secure data transfers over unsecured networks.
The vulnerability is due to a signal handler race condition – a software flaw in which the timing of signal handling and normal processing overlap unpredictably, potentially causing unexpected and harmful behavior in a program. In the case of OpenSSH, the vulnerability allows RCE as root on glibc-based Linux systems, presenting a significant security risk.
The vulnerability can be exploited by an attacker crafting a payload designed to exploit the signal handler race condition, sending it to the target system in an attempt to hit the exact timing where the race condition occurs. By repeatedly sending this payload, the attacker increases the chances of successfully exploiting the flaw, allowing them to execute arbitrary code as the root user.
If exploited, the vulnerability could lead to full system compromise, where an attacker can execute arbitrary code with the highest privileges, resulting in a complete system takeover, malware installation, data manipulation and the creation of backdoors for persistent access.
In an interesting twist, the vulnerability is a regression of the previously patched vulnerability CVE-2006-5051, which was reported in 2006. As the Qualys researchers explain, 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.”
The regreSSHion vulnerability can be found in OpenSSH versions earlier than 4.4p1 unless they have patched for CVE-2006-5051 and CVE-2008-4109. Versions from 4.4p1 up to, but not including, 8.5p1 are not vulnerable; however, the vulnerability can be found in version from 8.5p1 up to, but not including, 9.8p1 due to the removal of a critical component in a function.
To protect against the vulnerability, OpenSSH users are encouraged to quickly apply available patches, apply enhanced access control and apply network segmentation and instruction detection.
Discussing the vulnerability, Jeff Williams, co-founder and chief technology officer at application security software platform provider Contrast Security Inc., told SiliconANGLE that “it’s difficult to overstate the importance of OpenSSH to cybersecurity” and that the “flaw is extremely dangerous.”
“Unlike Log4Shell attacks, which could be completely contained in a single unauthenticated HTTP request, this attack is a bit noisy and takes ~10,000 attempts on average to succeed,” Williams explains. “In this case, the OpenSSH team accidentally re-introduced a flaw that they had already fixed, demonstrating that every team needs fully automated test suites that run with every build and help prevent regressions… particularly for security fixes.”
Ray Kelly, fellow at the Synopsys Software Integrity Group, describes the vulnerability as “about as bad as they come,” arguing that the “trifecta of remote code execution, root access and a wide-spread distribution across Linux servers makes this a hot target for threat actors.”
“Although an OpenSSH patch is available, deploying it across all affected systems – potentially impacting 14 million OpenSSH instances – poses a significant challenge,” Kelly added. “This vulnerability could persist for a long time, reminiscent of the Heartbleed vulnerability in OpenSSL from 2014.”