Security/PSA - OpenSSH Vulnerability in Linux systems

tl;dr Critical sshd vulnerability in Linux OpenSSH port.
https://nvd.nist.gov/vuln/detail/CVE-2024-6387

The bug’s called “regreSSHion” because the same bug was present back in 2006 and was fixed. Now it came back, but worse, as it allows remote access as root.

Most linux systems are affected. FreeBSD is also affected, I suspect NetBSD and DragonflyBSD too.

OpenBSD is not affected, because its implementation of the SIGALRM signal handler is built to avoid these kinds asynchronous calls that the linux sig handler does.

Distros based on musl aren’t affected, so Alpine, Void-musl and Gentoo-musl are safe. The bug is still there, but it might have different behavior.

Patch now.

7 Likes

From another thread, a non-video breakdown

Qualys link, who phronic credit with disclosure.

Not sure on disclosure terms/timing though

1 Like

The same qualsys link was in the description of the video. The CVE gives enough details as it is.
https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt

1 Like

Wow, the must one really does have a lot of linked resources

Thanks!

Last time I checked their report, was the bad windows WiFi driver, and it no useful info at all.

This is great stuff, cheers bud!

finally got round to double checking, and mixed blessings… some systems predate issue (boo, old)
seems Proxmox want the legacy stale approach

ii  openssh-server 1:8.4p1-5+deb11u3 amd64        secure shell (SSH) server, for secure access from remote machines

unattended upgrades upgraded a bunch of the others… which was handy… just a quick reboot to make sure…

3 Likes

It’s getting a bit confusing on what versions are vulnerable, anyone found a definitive list of vulnerable or fixed versions?

For example:

The vulnerability resurfaces in versions from 8.5p1 up to, but not including, 9.8p1 due to the accidental removal of a critical component in a function.

I have supported systems upgraded to 9.2p1-2, 8.9p1-3, 8.2p1-4 and according to many news articles these are still vulnerable?

My Proxmox VE 8.2.2 is running 9.2p1-2+deb12u3, @Trooper_ish just curious what Proxmox version do you have?

Good thing I’m paranoid I guess, so I VPN into SSH jump host first.
:frowning_face:

2 Likes

Also @moderators can we pin this, this is big.

2 Likes

am only on proxmox v7

I guess I really need to look into 8 before EOL at the end of this month…

Okay, upgraded to proxmox8 20 mins before work.

All worked fine…

Loving ZFS replication for backups

2 Likes

I updated from 7 to 8 in place and it was fairly painless.

1 Like

pinned for two weeks. :+1:

6 Likes

Yay!!!

1 Like

I’ve seen a couple of videos on this. My RHEL9 and Rocky9 servers are affected. RHEL8 and derivatives are unaffected. Thankfully, though, SSH is blocked on the public network for both of my systems: you have to be using the Wireguard tunnel into my Linode to SSH into it, and you need to be on my LAN to access my main homelab or connected to the Wireguard tunnel running on my PFSense box to connect to the physical machine.

Honestly, though, this isn’t that severe of a bug. The exploit requires a race condition in order to get things to line up well. So it isn’t exactly the most reproducible bug. And you have to wait on the SSH server login timeout to expire - which could be really lengthy. Though on the other hand, who knows how long it existed in the project before the security researchers could confidently say this is the bug and here’s the cause.

2 Likes

Someone was reporting it would take 7 days to successfully exploit the vulnerability with one method. But this doesn’t take into account targeted attacks and improvements in the exploit’s algorithms. You could get the race condition to kick in, in maybe 2 days. The vulnerability itself should be patched on everyone’s systems regardless. It’s bad enough when people never patch and run outdated software on the internet and become part of the botnet. It’s particularly egregious when patches aren’t available and you’re kinda SOL even when you want to patch.

4 Likes

Yeah. I updated my RHEL 9 system right as I was hearing about this vulnerability and I actually went through the update list to see if OpenSSH was there, but it wasn’t. It wasn’t until I saw Brodie Robertson’s video on the issue that he confirmed RHEL 9 does not have a patch, yet.

4 Likes

I’m actually surprised. This vulnerability seems like a pretty big deal, but the patch rollout seems slower than I’m used to.

My Debian Bookworm boxes also do not have a patch yet.

My Ubuntu 20.04 LTS servers have an old enough version of OpenSSH that they are unaffected.

2 Likes

Some outlets have reported that it is hard to execute this attack. Hammering on the server for several hours and meeting certain criteria. AFAIK the successful attack was carried out on a 32-bit system not a 64-bit one. I guess this is why the patch rollout goes slow.

5 Likes

At work we (and because work is also at home), and I use fail2ban on any servers that have SSH open to the public internet (so my Linode servers are included here).

Does something like fail2ban (with a reasonable default setting) mitigate this risk? I would assume so, since it means that anyone hammering a system would end up blocked by fail2ban before the race condition could end up being a problem… unless they got lucky on the first 3 attempts?

2 Likes

Given that it’s a vulnerability on connection, I think f2b would work to prevent it.

2 Likes

The only POC that I could find for this vuln shows that it took 8 hours to exploit on a 386 system, and they switched to that after they failed to exploit an amd64 system because it was taking too long.

It’s another one of those technically vulnerable bits of code that everyone makes a big stink about, but it’s only exploitable if you have a lot of chains that have fallen short.

4 Likes