They have named this vulnerability “regreSSHion”, since it represents the re-emergence of a bug that was previously patched in 2006
That’s a great name
Agreed, but I had to disable autocorrect to type it on my phone.
Playful and descriptive!
The new vulnerability, assigned CVE-2024-6387, allows for unauthenticated remote code execution (RCE) with root privileges, posing a severe threat to affected systems.
Oh, fuck. Guess this is my day now.
If I’m not mistaken, it seems like this is a timing attack and you need a lot of attack attempts to make it work. If you have like a fail2ban rule for ssh it should mitigate this attack to quite some degree, right? (Of course updating would still be the best).
While statistically unlikely, it would be possible to exploit the vulnerability on the first attempt
That’s true.
the in depth technical details
TL;DR; sigalarm handler calls syslog which isn’t safe to call from a signal handler context.
Their example exploit needed about 10k attempts to get a remote shell so it’s not fast or quiet, but a neat find regardless
I can already imagine the log generated will be a hint. We usually automate those anyway as it is closer to (D)DoS too.
Looks like Debian and Ubuntu have shipped patches, but I’m not seeing them show up in the RHEL-derivatives just yet, but I’m sure that’ll be soon™.
The full write-up can be found here and should be fairly readable for users of this forum.
Some quotes that I thought were interesting:
With a heap corruption as a primitive, two FILE structures malloc()ated in the heap, and 21 fixed bits in the glibc’s addresses, we believe that this signal handler race condition is exploitable on amd64 (probably not in ~6-8 hours, but hopefully in less than a week). Only time will tell.
So 64-bit systems seem to be a bit more resistant to this it seems? But I can’t be completely sure given how much I’ve read about this yet.
This vulnerability is exploitable remotely on glibc-based Linux systems, where syslog() itself calls async-signal-unsafe functions (for example, malloc() and free()): an unauthenticated remote code execution as root, because it affects sshd’s privileged code, which is not sandboxed and runs with full privileges. We have not investigated any other libc or operating system; but OpenBSD is notably not vulnerable, because its SIGALRM handler calls syslog_r(), an async-signal-safer version of syslog() that was invented by OpenBSD in 2001.
It seems that non glibc-based systems also could be vulnerable, but they have not yet tried to demonstrate it yet (or have tried and not been successful).
And OpenBSD wins again it seems.
Yeah they were experimenting with 64bit exploitation when this signal handler got some focus regarding a (likely related) deadlock so they rushed to disclose their findings to the project to minimise the possibility of having eyes on this vulnerability
It’s shit like this that makes me convinced that governments can easily hack into pretty much every system
I mean, on TV every character seems to be able to hack any system in a few seconds.
They clearly must have done some research by watching some NSA hackers who can hack every system.
They probably can. jut every hack done has the possibility of spoiling the exploit. A good exploit can cost a million $. So if hacking you is worth more then say 100k to them, you’re in trouble. Otherwise they will only target you with everyday surveilance.
Well only if they know about it before it gets patched…
That’s why there is a huge market for 0-day exploits.
Isn’t there attempts to sneak in vulnerabilities with new commits?
Yes, targeted attacks like that definitely exist, most famously maybe the most recent pressure to merge a vulnerability to the xz library by actor “Jia Tan”:
The NSA is doubtless sitting on a trove of these types of vulnerabilities to use when they really need access to something.
Most can’t, but that’s why clandestine cyber-intelligence firms like NSO group exist.
That’s a spooky one. From first glance - 500 employees and zero click takeovers of phones? Yikes. Makes me want to not have a phone… Ofc Google/Apple/USA have had this capacity for ages
Someone find the commit where they accidentally removed this critical component 😄
Good thing I’m on vacation for the next week and have my PC turned off. Remind me to update on Saturday
The fun thing about regressions: these things affects you if your system is new enough that it has the behaviour reintroduced. Which means you are less likely to be hit if you are using Debian Stable (or even Oldstable) than, say, Sid (unpatched at the time of writing this comment) or Arch btw.
My OpenMediaVault machine (based on Debian Oldstable) uses OpenSSH 8.4p1, so it’s old enough not to have the bug
I set up a wireguard VPN network between my computers and servers, and then firewalled off all services except Wireguard, and a few services on one server. That one server is my weak point, but even it has sshd firewalled off except through the Wireguard subnet.
It’s stupidly easy to set up WG subnetworks. I’m not a networking guy, and it was trivial for me to do. If u can run an ssh server, you can set up a Wireguard subnet: just do it.
Yeah. Some services you kinda want accessible directly, but ssh really isn’t one of them. Even though it should be safe, as that’s it’s intended purpose, putting a VPN in front of it makes a lot of sense, especially with how easy it is to setup these days. Anything used for administration is systems should be behind one.
Wireguard really changed the landscape, for me, and my entire approach to networking. Suddenly, VPNs became fast and easy, and where previously impractical for casual (hobbyist) admins, it made creating enterprise-grade secure subnets easy. It’s astonishingly stable and reliable, such that my initial concerns about cutting off all access except through the VPN - once a truly nerve-wracking concept - is now a no-brainer. It’s made my network administration easier and more secure. My firewalls are simpler.
Wireguard is one of the biggest high-impact, low-visibility networking game changers I’ve seen in decades.
There is definitely a shift away from traditional VPNs these days since VPN tunnels tend to be more open and permissive. You can obviously secure a tunnel and limit network access, but you are still directly accessing the networks and resources that you do allow, remotely.
I was running Kasm for a while and I really liked this approach to secure remote access. I could effectively spin up a Ubuntu docker image and access it remotely through the browser. Secured the web portal with my IdP which requires MFA and I would login remotely and launch various apps and desktops.
They are non persistent in nature, so once you log off and destroy the instance you would effectively get a new desktop the next login.
Generally works pretty well
Limit source ip access in the Firewall is my way to avoid this.
Maybe it is time to move to something new
Also why does sshd run as root. I deal like ssh could use some least privilege
Preliminary note: OpenSSH is one of the most secure software in the world; this vulnerability 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.
When you log in to an ssh terminal for a shell, it has to launch the shell process as the desired user. Needs to be root to do that.
Can’t it use built in OS mechanisms for that? Surely you could figure out a way to only give it permissions it needs. Maybe break it up into two separate processes.
That just sounds like root with extra steps (trying to implement OS security policies in a remote terminal utility)
Root because it use port 22. I think anything lower than port 1024 requires it. But if this is true, then you can try change the port it is listening to something higher than that.
Jokes on you, I run Centos 7!
