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. ®
Thanks- I wasn’t sure if someone with SSHD could connect to my system if i had SSH installed-
“Ok thanks- im pretty sure I run the newest mint- but will check when I get home.”
OK, I found something very useful for next time this happens so add it to your “useful commands” list everyone should have. I should have thought of it sooner.
“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.”
Here is how you check your versions of everything including OpenSSH.
” apt list —installed “
Here is mine:
openssh-client/focal-updates,focal-security,now 1:8.2p1-4ubuntu0.11 amd64 [installed]
So I am good. And if I ever update it... It will already come with the new patch included.
wow, thanks. good command to know- here is what mine listed
openssh-client/jammy-updates,jammy-security,now 1:8.9p1-3ubuntu0.10 amd64 [installed]
Yours looks like it is vulnerable from what the list says?
The list is kind of confusing...
Yep- the other fellas though said since i don’t have SSHD which is the server, and i only have the client (ssh)- i should be ok?
Well here is the problem... Some “Client” APPS also build a local server to work. Most P2P clients do this because they are also a server for incoming/shared traffic. So it depends on what you are using or might use in the future. I can’t see Ubuntu/Mint just letting this go without a security patch update. If I can get caught up I will go read chatter on the Mint forums to see what they are saying about it.
Thanks for the link- I’ll check it out too.
I didn’t find anything... Maybe they are not worried about it as out of the box default “Standard use”. Maybe it has already been dealt with awhile back. But any of us who connect servers together or utilize local/external node traffic servers do need to worry. It needs to be fixed regardless of preferred use. It is a security hole whether we use it or not.
Know what? I would just run a full CLI update and upgrade to see if it gives you a safe version.
I suggested CLI update and upgrade because I have noticed the GUI update manager is adding promotional apps I do not want or need. You have to pick through these options and eliminate some. The CLI just plays with what you already have installed.
cli update? not sure what that is? or how to do that?
ok thanks- I’m sure the next upgrade will deal with it- but liek you said, maybe it already has through incremental updates- seems liek they woudl be right on top of it with a fix-
Sorry about that, CLI -Command Line Interface... The Command Terminal. Sometimes it does certain things better than the GUI applications do. Updates and upgrades are two of those. I have found they are adding and “suggesting” stuff you don’t really need or want in the regular update manager app so you have to pick through and exclude those.
A terminal update and upgrade is quick and easier and will only affect what you already have installed with no extra stuff unless it absolutely needs a new additional dependency for one of the new upgrades. :)
As you know it is the the same old:
sudo apt update
sudo apt upgrade
But if you have it set to update it’s self then like you say if you need it they should send it. :)
thanks, i did those the other day- im all up to date- but my SSH is still in the affected range it seems-
Well then that is all you can do at this time then. :)
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.