Posted on 07/02/2024 10:59:45 AM PDT by ShadowAce
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.
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. 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. ®
“Since I posted this a few minutes ago, I checked my available updates, and my distro already has the newest package ready to DL with the fix.
I love Open Source!”
And it wasn’t packaged with 20 other garbage downloads that break other stuff at the same time. :)
MS, fix one issue while creating five others.
Ok, thanks. I’m not too versed in commands and such- but will try them when needed- have had to do several when things went awry- or when installing some program not in the app repository.
You use mint dont you? If so, I’ll check the update app again- maybe they have it there today
Yes, there is one Ubuntu security update in there but it doesn’t have any references to what the patch is for... I’m sure they are top of it... Or our version is new enough we don’t have to worry. In which case we will not see a security update for this particular issue.
Thank you. Will give it a go tonight.
Ok thanks- im pretty sure I run the newest mint- but will check when I get home.
I run OpenSUSE 15.5. Here is their statement:
“Only SUSE Linux Enterprise 15 SP6, SUSE Linux Micro 6.0, openSUSE Leap 15.6 and openSUSE Tumbleweed were affected by this problem.”
ran the command and it said SSh wasn’t installed, so my system wouldn’t be vulnerable then?
That would be correct. You're good to go.
Yep. SSH (OpenSSH) is optional on many systems, especially if they have a desktop GUI interface. If it's not installed, it certainly can't cause trouble. :-)
Thanks- i have lots to learn about linux still
thanks- i forget that soem of the posts on linux are abotu servers or systems with other stuff on them-
well that is weird- i checked with ssh -V and came up with
“OpenSSH_8.9p1 Ubuntu-3ubuntu0.10, OpenSSL 3.0.2 15 Mar 2022”
when i run sshd —help - i get
“Command ‘sshd’ not found, but can be installed with:
sudo apt install openssh-server”
Not in the Windple duopoly?
We’ll get you, our little pretties!
ok now im confused-
it seems i have the client when i check with ssh -V
but not the server when i check with sshd -V
woudl i have to have both in order to be vulnerable to the exploit?
No—I think you are safe.
Roger that. The sshd server is the vulnerable component.
the client (ssh) allows you to connect via ssh to other computers
the server (sshd) allows others to connect to your system, so if you don’t have the server no one can connect to you. If you don’t need it, you shouldn’t have it :-)
ah ok, thanks, sorry for the late reply-
Great- thanks for helping- this stuff is confusing to me these days
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.