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).
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
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.
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.
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.
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.
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).
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.
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.
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.
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
Yes, targeted attacks like that definitely exist, most famously maybe the most recent social pressure to merge a vulnerability to the xz library by actor "Jia Tan":
This started a whole discussion about relying on (often unpaid) volunteer work for critical systems and the pressure and negativity these people face, which is a discussion that was absolutely needed, and which we are still lightyears away from fixing.
(I can only recommend reading the whole story around this issue, which boils down to Microsoft admitting they rely on an open source project for something they consider critical to their customers, but not willing to pay the maintainer a bounty for fixing the issue)
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.
The new vulnerability, assigned CVE-2024-6387, allows for unauthenticated remote code execution (RCE) with root privileges, posing a severe threat to affected systems.
