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. ®
OH SSHit
No matter how bad the news is, those little guys always make me happy.
This was what my son was frantically trying to figure out last night when a tornado warning sent us into the basement. He’s worked so hard to set up our secure server and just like that he had to figure out how to keep it secure.
I love Open Source!
Yet another reason to restrict network access to a sshd endpoint.
Ping...
Well..... That’s not good.
Yep! A simple "apt-get update && apt-get upgrade" did it for all my systems -- the fix was waiting for me.
The Register tends to get a little breathless about vulns. This one is very difficult to exploit, but you have to read deep into the article to discover that. Oh well, they deserve the clicks...
alias update='apt update && sleep 2 && apt list --upgradable'
I just did an update and it looks like this is the latest fo Kubuntu: OpenSSH_9.6p1
im running mint, but haven’t got any update recommended in the update app-= where woudl i go to find out if there is an update?
apt update -y && apt list --upgradable
sshd --helpIt will print out its OpenSSH version and some usage info (since --help is not a valid option). You should see a string like this:
OpenSSH_8.2p1 ....That's the OpenSSH version. Check it against the ranges that are vulnerable. If yours is not vulnerable then you're okay. If your is potentially vulnerable, use a command like the one ShadowAce posted above in #12:
sudo apt update && sleep 2 && apt list --upgradable
Thank you, I will do that tonight-
Thank you for the ping... :)
apt update -y && apt list --upgradable should be
apt update && apt list --upgradable
.
Get rid of the -y flag. It's not supported.
I got the same list with or without the -y flag. Ubuntu/mint...
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.