Nasty regreSSHion bug in OpenSSH puts roughly 700K Linux boxes at risk

Glibc-based Linux systems are vulnerable to a new bug (CVE-2024-6387) in OpenSSH's server (sshd) and should upgrade to the latest version.

Infosec researchers at Qualys published their findings today, revealing that sshd is vulnerable to a race condition that could allow an unauthenticated attacker to achieve remote code execution (RCE) on potentially hundreds of thousands of targets. Successful exploitation could give intruders root-level access to a system, allowing them to potentially get away with virtually anything.

Of the 14 million possibly vulnerable sshd instances that show up on Censys and Shodan scans, Qualys believes that roughly 700,000 of these internet-facing instances could feasibly be hit by regreSSHion – the name researchers gave to the flaw based on its roots.

"In our security analysis, we identified that this vulnerability is a regression of the previously patched vulnerability CVE-2006-5051, which was reported in 2006," said Qualys. "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)."

Damien Miller, founder of the portable OpenSSH project and maintainer since 1999, said in an online discussion that anything running glibc is probably vulnerable. Systems with 32-bit architectures have been proven to be so, and 64-bitters are likely at risk too.

The notable exception here is OpenBSD. Systems that run the OS can safely ignore all of this thanks to a security tweak made in 2001.

Per Qualys's more detailed advisory, if a client doesn't authenticate within the LoginGraceTime – a parameter that sets the maximum time a successful authentication attempt to sshd can take, set to 120 seconds by default – then the server's SIGALRM handler is called asynchronously.

This signal handler can then call functions that aren't async-signal-safe, such as syslog() – an oversight attackers can exploit to ultimately execute arbitrary code. From there, it may be possible to operate at the root level, perform a full system takeover, deploy malware, and implant backdoors, all while evading security measures.

• Juniper Networks flings out emergency patches for perfect 10 router vuln
• Poyfill.io claims reveal new cracks in supply chain, but how deep do they go?
• CISA director: US is 'not afraid' to shout about Big Tech's security failings
• Police allege 'evil twin' of in-flight Wi-Fi used to steal passenger's credentials

A quick side note: That "security tweak" in OpenBSD we mentioned is related to the syslog() call. From 2001, OpenBSD's SIGALRM handler calls syslog_r() instead – a safer version of syslog() and as such isn't affected by regreSSHion.

While the consequences of a successful exploit could be dire, actually doing so would take some patience – or a decent amount of parallelization. According to the OpenSSH team and its release notes for version 9.8, which includes the fix for CVE-2024-6387, in lab conditions it took between six and eight hours to beat the race condition.

Qualys's tests were a touch quicker, taking around three to four hours and in the region of 10,000 attempts to beat it. However, it took six to eight hours to obtain a root shell because, due to ASLR, the researchers could only predict glibc's address half the time.

"This vulnerability is challenging to exploit due to its remote race condition nature, requiring multiple attempts for a successful attack," it said. "This can cause memory corruption and necessitate overcoming Address Space Layout Randomization (ASLR). Advancements in deep learning may significantly increase the exploitation rate, potentially providing attackers with a substantial advantage in leveraging such security flaws."

This vulnerability is challenging to exploit due to its remote race condition nature, requiring multiple attempts for a successful attack

All versions of OpenSSH earlier than 4.4p1 are vulnerable, unless they have applied patches for both CVE-2006-5051 and CVE-2008-4109. Versions from 8.5p1 up to but not including 9.8p1 are also vulnerable. Versions 4.4p1 up to but not including 8.5p1 are unaffected due to CVE-2006-5051 being patched as standard.

In addition to applying the patches, Qualys recommended that organizations limit SSH access through network-based controls, and segment networks along with monitoring systems that alert admins of exploit attempts.

Despite the regreSSHion bug, Qualys had nothing but positive things to say about the OpenSSH project, saying that the discovery is "one slip-up in an otherwise near-flawless implementation."

"Its defense-in-depth design and code are a model and an inspiration, and we thank OpenSSH's developers for their exemplary work," it added.

Ubuntu has updated versions here, and NixOS has also been busy over the past few hours – users can go here, at least.

Check your distro for updates – there will probably be some. ®