Pre-auth RCE to root in OpenSSH server: 700,000 instances exposed

Updated July 3, 2024: Current widely circulated POCs are fake, fake, fake.

A critical vulnerability in certain versions of the OpenSSH server can be exploited remotely by an unauthenticated attacker to gain root.

The race condition vulnerability, allocated CVE-2024-6387 and affecting most Glibc-based Linux  versions, was identified and reported by Qualys.

A technical write-up of bug, dubbed "regreSSHion" is here.

It is rated CVSS 9.2 (CVSS 4.0).

OpenSSH vulnerability CVE-2024-6387: Ubuntu, RHEL 9, others push patches

Ubuntu (versions greater than 22.04 affected) and Debian were among those pushing patches to their distributions this morning.

For Red Hat, only RHEL 9 is affected. SUSE's advisory is here. AWS Linux did not appear to have published a bulletin as The Stack published.

It takes between six hours and a week (depending on the OS being targeted) of persistent effort (approximately ~10,000 attempts) for an attacker to exploit the race condition and gain a root shell however.

Qualys said in its advisory that exploitation attempts can be identified by seeing “many many lines of ‘timeout before authentication’ in the logs.”

It has provided a technical breakdown of the vulnerability but will not be sharing exploit code. The security firm said if sshd can’t be updated or recompiled, a mitigation is to “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” it noted.

Defenders may, presumably, also want to consider implementing rate-limiting options on SSH access that deny connections from an IP address that has attempted to initiate X+ connections over Y time period.

As security specialist Jake Williams noted: "Most orgs don't need SSH open to the whole Internet. Yes, ACLs [access control lists] are a pain to use. But you're getting a lot back in security. That's true for times like these, but it's also makes credential compromises harder to meaningfully exploit. As an aside, if you can't do IP ACLs for SSH (and everyone *can*, it's just a question of overhead to maintain), consider changing the default port for SSH. In some testing, that's dropped my failed login attempts by more than 95% (98%+ if you don't make it something obvious like 2200, 2222, or 2022)."

OpenSSH vulnerability CVE-2024-6387

OpenSSH is a suite of secure networking utilities based on the Secure Shell (SSH) protocol. It is used for remote server management and secure data communication and is included in multiple macOS and Linux systems.

"This vulnerability is a regression of the previously patched vulnerability CVE-2006-5051, which was reported in 2006," said Qualys, adding that “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)."

Ray Kelly, fellow at the Synopsys Software Integrity Group, said in an emailed comment: "A trifecta of Remote code execution, root access, and a widespread 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.  This vulnerability could persist for a long time, reminiscent of the Heartbleed vulnerability in OpenSSL from 2014."

Qualys said its analysis suggested 700,000 vulnerable instances were publicly exposed. No exploitation has yet been seen in the wild but the scale of exposed targets means threat actors will no doubt be working overtime to understand the exact attack path and start building exploits.

Security researchers at Wiz however suggested that widespread exploitation seemed unlikely: "Our reasoning is that currently known exploitations rely on distribution-specific conditions (ASLR for example) and glibc-version-specific struct layouts, which means an attacker must know in advance what Linux distribution they are targeting in order to build a functional exploit. This requirement makes the vulnerability inappropriate for widespread opportunistic exploitation. 

"Furthermore, successful exploitation usually takes several hours of login attempts in total. If attempted continuously by an attacker trying to successfully exploit the vulnerability as fast as possible, the exhibited behavior would be similar to that of a password brute-force attempt, meaning that any existing brute-force prevention and detection measures would effectively mitigate it, making the success rate of this technique quite low in well-protected."

Updated July 3: POCs are circulating widely. They are, to date, fake.

As Qualys put it, with reference to a specific POC: "Many people have asked us about an alleged proof of concept named "7etsuo-regreSSHion.c": it is not a proof of concept, it is essentially empty code (it might even be dangerous to compile and execute, we have not checked). It is not just the shellcode that is missing, everything else is missing too: the key-exchange code does nothing, the public-key code does nothing useful, etc etc. It looks great but it does nothing. A working proof of concept for this vulnerability will be much longer and complex, and will take much more time to write than this..."