Nasty regreSSHion bug in OpenSSH puts roughly 700K Linux boxes at risk 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 …
On RHEL 9.4 it's patched:
yum list --cve CVE-2024-6387 | grep openssh
openssh.x86_64 8.7p1-38.el9 @anaconda
openssh-clients.x86_64 8.7p1-38.el9 @anaconda
openssh-server.x86_64 8.7p1-38.el9 @anaconda
openssh-askpass.x86_64 8.7p1-38.el9 updates-appstream
openssh-keycat.x86_64 8.7p1-38.el9 updates-baseos
Actually, no, RHEL9 and CentOS 9 Stream are NOT patched, I just checked. In fact, the RHEL9 package hasn't been updated since April and the CentOS 9 Stream package was updated a month ago. So there's no way they're patched.
Your "yum" command is invalid and will produce a list of every available package. the dnf man page straight out says:
--cve=<cves>, --cves=<cves>
Include packages that fix a CVE (Common Vulnerabilities and Ex‐
posures) ID (http://cve.mitre.org/about/), Eg. CVE-2201-0123.
Applicable for the install, repoquery, updateinfo, upgrade and
offline-upgrade (dnf-plugins-core) commands.
Notice 'list' isn't listed.
# dnf repoquery --cve=CVE-2024-6387
Will return.. nothing
Ahh, thanks. I checked today and noticed I didn't get a package update yet (Alma Linux 9) so I created a few rules to block the port for all IP addresses but mine. I guess I didn't really need to do that then, but that's OK. I would expect it to be fixed regardless, though.
P.S. Oops, I see that info is not quite correct. Thanks anyway :-)
This post has been deleted by its author
While the consequences of a successful exploit could be dire, actually doing so would take some patience. According to OpenSSH 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.
I'm not sure I agree, you could finish work for the day and your machine is pwned by the time you start work the next day....
glibc was also implicated in the recent attempt to subvert openssh by the attack on libzma via its build system. IFUNC was used by the attack to redirect calls to openssh's authentication to the attacker's own routines. IFUNC is part of glibc, but for any executable that performs security checks and depends on a third party library IFUNC sounds like a terrible, asking-for-trouble piece of functionality. It supposed to be used by developers to be able to have several different versions of a function loaded at once, and to be able to select (at run time) which one is used. I've never ever heard of a developer doing that, the gnu documentation on it seems a bit vague on the matter and anyway confesses to there being shortfalls in the documentation. Given what nearly happened to libzma / openssh, and the strong possibility that others are trying (and may be have succeeded) with other commonly used library dependencies, getting rid of ifunc or getting rid of glibc sounds like a good idea.
I don't know if other C libraries out there have a similar feature...
I,m wondering. Having installed fail2ban with exponential block time, wouldn't that mean it takes, on average, a significant amount longer to penetrate (3 failures within 8 hours starts at 4 hours blocking and doubling every next block event)?
Sure, the first exploit hit could already be fatal, but if you play the odds, it may give you some breathing room to patch, wouldn't it?
(BTW, already patched my servers)
I'm not sure if a timed out login attempt would be flagged by fail2ban as a "failed" login per se and therefore might not be blocked. So might need some config tweaking to recognise it (or at least verifying) before relying on it.
Sorry, I haven't checked so probably should shut up, but wanted to comment in case someone sees your question and decides fail2ban is "probably good enough"!
I was wondering the same thing. Does timeout count?
We just changed the firewalls to an even more strict policy on white-listed IP's that can connect to SSH and commenced patching. The patches are easy to apply via the standard terminal update procedures. Hats off to Canonical for having the patch ready in such a timely manner.
Canonical/Ubuntu have published the following mitigation, which may be useful if you can apply this change faster than you can install the patch:
"Set LoginGraceTime to 0 in /etc/ssh/sshd_config. This makes sshd vulnerable to a denial of service (the exhaustion of all MaxStartups connections), but it makes it safe from this vulnerability."
Copied from here: https://ubuntu.com/security/CVE-2024-6387
A better option would be to:
# iptables -A INPUT -p tcp --dport 22 ! -s a.b.c.d -j DROP
or for example, a network:
# iptables -A INPUT -p tcp --dport 22 ! -s a.b.c.d/24 -j DROP
Where a.b.c.d is the correct IP address you wish to accept, or a.b.c.d/24 is the correct network and subnet.
The ! of course means "not" DROP from that source in this case. (doing it that way saves needing two rules for DROP and ACCEPT)
Fixed for me now on all boxes with non-rolling distros (e.g. Arch had this fixed before I went to be this morning). The one I was most concerned about was an Alma Linux 9 box in a datacenter but those packages just hit my repos (Alma specific nomenclature in the package names while same base package and version)
You people who downvote are ridiculous... moreover, one of the recommendations by Qualsys was to mitigate this using "network based access controls". Since I don't have access to the routers upstream from me, that prevents any attack from reaching a service listening on the port. This has nothing to do with logins. Not sure what your problem is, but you're pathetic.
I'm running a server that accepts data from almost 100 different corporations. If I want do drop everything outside a single CIDR, that CIDR will have to be 0.0.0.0/0.
Whitelisting is what they are talking about.
And yes, We use Google on the business side, so I've set up an SSO process that logs my IP address & updates our (AWS) security groups to whatever doctor's office or grocery store I'm working in while my wife is at an appointment. It wasn't particularly hard to set up.
I have to use Linux at work but this has given me the push to try and go Windows at home. I'll need one of the simpler distros to get started though. I hear good things about Windows 7 for people used to Ubuntu. Might need to go dual-boot for a while until I find replacements for all my apps. Wish me luck guys.
It's OK, we grok the joke - including how long a similar problem on Windows would take to be detected, buried within Microsoft, fixed, held back to the next Patch Tuesday, applied, rebooted and the resulting breakage fixed the following month - maybe. Did you miss that bit?
Original AC (for other personal reasons) here.
I am also 100% Linux and other Unix systems. Some have even called me a fanboi, but like you, I thought this was a funny comment.
You and I aren't the butthurt fanbois I was talking about - the ones so into the coolaid that instead of just ignoring it if they didn't think it was funny, they had to actively downvote it, and then assumed by my reaction to that that I wasn't myself a linux/unix fanboi, but some windows cultist.
That's the sad part I was pointing out. That level of cultism does our community no good at all.
My colleague only stopped with Windows because the Prolific RS-232 drivers got all fscky.
(A fantastic story of cheap clones causing upstream vendor to change chip slightly, rendering their driver inoperable with clones and Window's inability to cleanly support multiple proprietary driver versions)
Be aware that if you upgrade (rather than install) a machine running OpenSSH sshd to version 9.8 you need to restart the ssh daemon otherwise you will not be able to login via it.
More info: https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/issues/5
A useful warning but it's worth noting (as described in the Arch package issue you linked) that's because of an unrelated change between 9.7 and 9.8, so won't apply where packages have a backported fix, nor if, unlike Arch, the restart is done for you by package scripts (a choice with pros and cons).
Also, in this case I think the potential for exploit is after the long-running sshd process has exec'd itself meaning the fix is effective without restarting sshd, but the conservative assumption and general case is that a restart is necessary so this should be standard practice anyway.
It's already patched in Mint 21.3
Got to say something about updates : they rock. Unless you really don't pay attention and don't do the updates. Most of the time when i read about a critical update either it's in the updates queue or already been updated. Mint's update management really is easy.
Nothing but good words about Mint and Linux in general. Switching 23 years ago was the best decision i ever made.
Good day.
So Linux is also insecure by design? ;-)
The real issue here is that, what is supposed to be the epitome of secure code, makes a rookie mistake in using signal handlers. Not only that, it ends up calling a non-async-signal-safe function buried under layers of indirection, making any future updates susceptible to repeating the same mistake.
Signal handlers should be avoided if possible. If not possible, the most the signal handler should do is set some global variable and then let the main context do the heavy lifting. Keeping track of which library functions are async-signal-safe on every C library implementation is doomed to failure.
I suspect they've used a signal handler for the purposes of being very portable, but even then there's no particular reason to implement the desired timeout functionality with SIGALARM.
For a Linux implementation, there's signalfd - which is where signals are delivered via a file descriptor. You can include this in a call to select() or epoll(), along with other fd's. It's a very nice way of handling signals, because you're doing so at your convenience, in the main thread context, with no limitations on what can be safely called having read the fd. Far better than a fully async handler where dangerous things to do can be easily done!
For a more portable timeout method, openssh could perhaps have used select(); it sounds like it's waiting for input at the relevant point of code, and select() called with a timeout is perfect for that.
Whenever you get a problem like this -- a simple problem with an even simpler fix ("Don't use non thread safe code by default unless you really, really, know its thread safe") -- the advice is always "Upgrade to the latest version. Now!".
This carries with it a number potential problems because unless this update fixes this bug, and only this bug, there's no guarantee that the slew of other changes would not introduce further bugs. Obviously this can be checked by regression testing -- but, seriously, the amount needed suggests that its unlikely that the coverage would be 100%.
I'm used to controlled firmware fixes for certified embedded products where only the bug cited is fixed in that branch of the release. The reason for this is obvious. It also suggests that fixing bugs should be done in a less scattergun approach. Constant harping about "the latest" might keep a bunch of programmers churning away productively but it doesn't produce stable products.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
