regreSSHion: Should We Panic About the New OpenSSH Vulnerability?
This article takes a detailed look at regreSSHion, a newly discovered vulnerability in OpenSSH that affects glibc-based Linux systems.
Join the DZone community and get the full member experience.
Join For FreeWhat Is the regreSSHion Vulnerability (CVE-2024-6387)?
regreSSHion is a newly discovered vulnerability in OpenSSH that affects glibc-based Linux systems. regreSSHion (CVE-2024-6387) may allow arbitrary code execution with root privileges on systems with default configurations.
Why Is Everyone Worried About the regreSSHion Vulnerability?
Everyone is worried about the regreSSHion vulnerability because OpenSSH is a widely used utility for remote connection to different devices around the world. It implements the SSH (Secure Shell) protocol, which is integrated into most Linux distributions as well as macOS, OpenBSD, and FreeBSD. Furthermore, SSH is integrated into almost every device connected to the internet, from WiFi routers to baby monitors.
Affected OpenSSH Versions
Versions of OpenSSH up to 4.4p1, as well as those from 8.5p1 to 9.7p1 (inclusive), running on glibc-Linux, are susceptible to vulnerabilities. The OpenBSD version of OpenSSH is not affected, due to a security change introduced in 2021.
How To Mitigate a regreSSHion Vulnerability
Step 1: Update
First of all, you need to update the OpenSSH version if any updates are available.
The latest version of OpenSSH is 9.8/9.8p1.
- Ubuntu prepared packages with updated versions:
Ubuntu 24.04 - 1:9.6p1-3ubuntu13.3
Ubuntu 23.10 - 1:9.3p1-1ubuntu3.6
Ubuntu 22.04 - 1:8.9p1-3ubuntu0.10
See the Release page for more information.
- Debian:
bullseye (security), bullseye - 1:8.4p1-5+deb11u3
bookworm (security) - 1:9.2p1-2+deb12u3
sid, trixie - 1:9.7p1-7
More info is in the Debian bug tracker.
- NixOS adds changes to all of the unstable, 24.05, and 23.11 channels. You can find more info in the nixpkgs GitHub.
- FreeBSD OpenSSH versions are affected; you can find instructions on how to upgrade them in the Corresponding FreeBSD Security Advisory.
- You can follow the publication of package updates in distributions on the pages of other projects: RHEL, SUSE/openSUSE, Fedora, Gentoo, and Arch.
Step 2: If No New Version Available
If no new SSH version is available, access to SSH should be restricted via a firewall or by any other network security tool.
Step 3: Update OpenSSH Configuration
Set LoginGraceTime
to 0
to reduce the risk. Please note that this configuration can potentially increase the risk of denial of service attacks. You can do this manually or by using a simple remediation script.
How To Check If Your OpenSSH Is Vulnerable
The simplest method is to check the version and compare it with the affected list.
If you need to check many hosts, you can use the Python checker script by xaitax.
Does the regreSSHion (CVE-2024-6387) Vulnerability Means That Every Affected Version Will Be Hacked?
Not really. According to the official OpenSSH 9.8/9.8p1 release notes (linked in Step 1 above):
"Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with address space layout randomization (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. OpenBSD is not vulnerable."
But this does not mean that you don't have to update the version! It is possible that hackers can find a faster way or use the same bug for a different type of attack.
Technical Details and Why the Strange Version Order Was Affected
Next, here are some technical details about what happened here and why the strange version order was affected by regreSSHion. This happened because exactly this bug was already fixed some time ago, and because of this, CVE-2024-6387 was named regreSSHion, a conjunction of "regression" and "SSH''. Previously, this bug had an ID CVE-2006-5051 and was reported by Mark Dowd in 2006, but it was accidentally brought back in the OpenSSH 8.5p1 (October 2020).
The OpenBSD version of OpenSSH is not affected, because its implementation from 2021 uses SIGALRM handler calls syslog_r()
instead of syslog()
, which is used in the affected OpenSSH versions.
Why Did One Recommendation Include the LoginGraceTime SSH Option Update?
Per a more detailed explanation from Qualys, if a client does not authenticate within LoginGraceTime
(parameter specifies the time allowed for successful authentication to the SSH server, set to 120 seconds by default), then the SIGALRM
handler is called asynchronously.
But this SIGALRM
handler calls various not async-signal-safe functions (syslog()
, for example), which could lead to race conditions and allow a malicious code to run in the context of the sshd
's privileged code, operating with full root privileges.
Сonclusion
In the detailed explanation from Qualys, they especially mention that “OpenSSH is one of the most secure software in the world," and, “...this vulnerability is one slip-up in an otherwise near-flawless implementation." But this bug one more time highlights how important regression testing is and how it can prevent a resurgence of previously identified vulnerabilities.
Opinions expressed by DZone contributors are their own.
Comments