Pierluigi Paganini
July 01, 2024
OpenSSH maintainers addressed a critical vulnerability, tracked as CVE-2024-6387, that can lead to unauthenticated remote code execution with root privileges in glibc-based Linux systems.
OpenSSH maintained have addressed the vulnerability with the release of version 9.8 on July 01, 2024.
“A critical vulnerability in sshd(8) was present in Portable OpenSSH versions between 8.5p1 and 9.7p1 (inclusive) that may allow arbitrary code execution with root privileges. Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with ASLR. Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept. Exploitation on 64-bit systems is believed to be possible but has not been demonstrated at this time. It’s likely that these attacks will be improved upon.” . “Exploitation on non-glibc systems is conceivable but has not been examined. Systems that lack ASLR or users of downstream Linux distributions that have modified OpenSSH to disable per-connection ASLR re-randomisation (yes – this is a thing, no – we don’t understand why) may potentially have an easier path to exploitation.”
The has discovered the Remote Unauthenticated Code Execution (RCE) vulnerability in OpenSSH’s server (sshd) in glibc-based Linux systems.
The issue is due to a signal handler race condition, Qualys researchers state that the flaw poses a considerable risk because it affects sshd in its default configuration.
“The vulnerability, which is a signal handler race condition in OpenSSH’s server (sshd), allows unauthenticated remote code execution (RCE) as root on glibc-based Linux systems; that presents a significant security risk. This race condition affects sshd in its default configuration.” Qualys.
Searches using Censys and Shodan have revealed over 14 million potentially vulnerable OpenSSH server instances exposed to the Internet. Data from Qualys CSAM 3.0 shows that around 700,000 of these are external internet-facing instances, representing 31% of all such instances in their global customer base. Notably, over 0.14% of these vulnerable instances are running an End-Of-Life/End-Of-Support version of OpenSSH.
The flaw was introduced with the fix for another vulnerability, tracked as . This is a case of regression of a previously patched flaw, which means that a previously fixed bug has resurfaced in a later software release, often due to updates that unintentionally reintroduce the issue. The regression was introduced in October 2020 with the release of OpenSSH 8.5p1.
Maintainers pointed out that OpenBSD systems are not impacted by this vulnerability. The latest release also addressed a Logic error in ssh(1) ObscureKeystrokeTiming. The flaw was discovered by Philippos Giavridis and also independently by Jacky Wei En Kung, Daniel Hugenroth and Alastair Beresford of the
University of Cambridge Computer Lab.
“In OpenSSH version 9.5 through 9.7 (inclusive), when connected to an OpenSSH server version 9.5 or later, a logic error in the ObscureKeystrokeTiming feature (on by default) rendered this feature
ineffective – a passive observer could still detect which network packets contained real keystrokes when the countermeasure was active because both fake and real keystroke packets were being sent unconditionally.” states the advisory.
Follow me on Twitter: and and Mastodon
(SecurityAffairs – hacking, OpenSSH server)
