A new OpenSSH vulnerability discovered by threat researchers is the biggest security issue to appear in the utility suite in about two decades, creating the possibility for an attacker to gain root access to a system without any user interaction. The bug is an unauthenticated Remote Code Execution (RCE) vulnerability that builds on a prior issue that was patched out in 2006, and impacts only specific versions of the software either from before that time or the more recent updates beginning with the version released in March 2021.
OpenSSH vulnerability “regreSSHion” threatens recent versions of software
Called “regreSSHion,” or by the less memorable CVE-2024-6387, the OpenSSH vulnerability is essentially a re-emergence of 2006’s CVE-2006-5051. That means that very old versions of the software that were not patched for the 2006 bug are also vulnerable to this flaw, but the version 8.5p1 update (introduced in October 2020) appears to have made a change that accidentally made the vulnerability viable again. All versions from then to just before version 9.8p1 (which was just released at the beginning of July) are exploitable. All versions deployed on OpenBSD appear to be safe, however, due to a difference in how the signal handler calls syslog.
The new OpenSSH vulnerability was discovered and made public by the Qualys Threat Unit. It is particularly dangerous as it is an RCE that can be run against the software’s default configuration with no user interaction, and that provides root access. The company estimates that there are over 14 million potentially vulnerable OpenSSH server instances connected to the internet, with about 700,000 external internet-facing instances.
The actual details of the “complex” exploit process were not disclosed by Qualys, but the firm believes that knowledge of its existence will allow others to replicate their work before long. The RCE exploit was privately demonstrated to the OpenSSH team before disclosure, and is patched out as of version 9.8p1 (released July 1). The OpenSSH vulnerability could develop into a persistent issue, however, as it will require manual updating of outdated versions.
The RCE element and the lack of need for user interaction means that an attacker can essentially take over a target system fully by leveraging the OpenSSH vulnerability. This could give them a footing inside of firewalls and automated detection systems that could then be leveraged for network traversal and privilege escalation. The only specifics provided to the public about it are that it is difficult to exploit and would likely take an attacker multiple attempts to induce, but that deep learning could be leveraged to increase the likelihood of success. 32-bit versions of the software are also more readily vulnerable than 64-bit systems.
“Complex” RCE attack still not known to public, but remediation may be tricky
For some, remediating the OpenSSH vulnerability will be simple: just ensure that the software has been updated to the recently-released 9.8 version (unless a remarkably old version is in use). But Qualys projects that most will be dealing with systems that are “stuck” on a version in the RCE hot zone of versions from 2020 to 2024 and cannot be readily updated, which means a more complex remediation must be applied. The recommended process for immediate remediation unfortunately involves opening sshd up to an unrelated denial-of-service attack.
The good news about the OpenSSH vulnerability is that exploitation attempts have not yet been spotted in the wild. Successfully taking advantage of the exploit required about 10,000 tries to win a race condition using 100 concurrent connections under the researcher’s test conditions, or about six to eight hours to RCE due to obfuscation of ASLR glibc’s address. The attack will thus likely be limited to those wielding botnets when it is uncovered by threat actors.
Given the large amount of simultaneous connections needed to induce the race condition, the RCE is also very open to being detected and blocked by firewalls and networking monitoring tools. Qualys’ immediate advice for mitigation also includes updating network-based access controls and segmenting networks where possible.
Marc Manzano, general manager for cybersecurity at SandboxAQ, notes that an AI-based cryptography management platform can aid in detecting and locating vulnerable implementations that might be targets of the OpenSSH vulnerability: “This is an important finding as any vulnerability allowing remote code execution opens the door to malicious actors that can have catastrophic consequences. Modern cryptography management platforms help companies monitor where this vulnerable version of OpenSSH is present across the IT infrastructure, providing an effective and seamless solution to address this situation in a timely manner.”
Jeff Williams, co-founder and CTO at Contrast Security, points out that while the vulnerability is roughly comparable to Log4Shell the requirements to get to RCE make it much more readily detectable and unlikely to have as much of an impact: “It’s difficult to overstate the importance of OpenSSH to cybersecurity. Despite the stellar record of security from the OpenSSH team, this 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. I’m optimistic that this will enable providers to detect and prevent these attacks before they are successful. 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.”
But as Rogier Fischer (CEO and Co-Founder at Hadrian Security) notes, this does not mean that it is safe to ignore patching in this case: “While there is currently no proof of concept demonstrating this vulnerability, and it has only been shown to be exploitable under controlled lab conditions, it is plausible that a public exploit for this vulnerability could emerge in the near future. Hence it’s strongly advised to patch this vulnerability before this becomes the case”.
