Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

qualys.com

Post reply on HN
Print view View original

111–120 of 347 posts

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#111

Post by frankjr »

marcus0x62 wrote: post #54

Patch out for Arch Linux https://archlinux.org/packages/core/x86_64/openssh/ edit be sure to manually restart sshd after upgrading; my systems fail during key exchange after package upgrade until restarting the sshd service: % ssh -v 192.168.1.254 OpenSSH_9.8p1, OpenSSL 3.3.1 4 Jun 2024 ... output elided ... debug1: Local version string SSH-2.0-OpenSSH_9.8 kex_exchange_identification: read: Connection reset by peer C…

Same here. It's caused by the sshd daemon being split into multiple binaries. In fact, the commit which introduced the change mentions this explicitly:

> NB. if you're updating via source, please restart sshd after installing, otherwise you run the risk of locking yourself out.

https://github.com/openssh/openssh-portable/commit/03e3de416...

Edit: Already reported at https://gitlab.archlinux.org/archlinux/packaging/packages/op...

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#112

Post by daneel_w »

TacticalCoder wrote: post #62

And who was notoriously not exploitable? The ones hiding sshd behind port knocks. And fail2ban: would work too. And a restrictive firewall: would help too. I don't use port-knocking but I really just don't get all those saying: "It's security theater" . We had not one but two major OpenSSH "near fiasco" (this RCE and the xz lib thing) that were both rendered unusable for attackers by using port knocking. To me port-k…

Camouflage is after all one of nature's most common defenses. Always be quick with patching, though.

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#113

Post by singron »

qhwudbebd wrote: post #58

Once I'd finished upgrading my openssh instances (which are linked against musl not glibc) I thought it'd be interesting to have a poke at musl's syslog(3) and see if it allocates too and so is easily exploitable in the same way. But as far as I can see, it doesn't: https://github.com/bminor/musl/blob/master/src/misc/syslog.c Everything there is either on stack or in static variables protected from reentrancy by the…

If you are right about the allocations, then I think the worst it can do is deadlock since the locks aren't recursive. Deadlock in sigalrm could still lead to a DOS since that might prevent it from cleaning up connections.

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#114

Post by DEADMINCE »

yjftsjthsd-h wrote: post #105
DEADMINCE wrote: post #102

Earlier quoted context omitted.

SEL4 and derivatives. For starters. And if you want to simply go by vulnerability counts, as though that meant something, let's throw in MenuetOS and TempleOS.

Okay, let's say if you know something useful with a better record. TempleOS doesn't have network, so while it's genuinely cool it's not useful to most people. MenuetOS does have network but poor software compatibility. I would actually love to see a seL4 distro but AFAIK it's pretty much only ever used as a hypervisor with a "real" (normal) OS under it, often (usually?) Linux-based. We can certainly consider to what…

> Okay, let's say if you know something useful with a better record.

Oh, SEL4 is without any doubt useful, it wouldn't be as popular and coveted if it wasn't, but I think you are trying to say widespread.

However, you seem to have taken my examples literally and missed my point, which is trying to judge the security of an OS by its vulnerabilities is a terrible, terrible approach.

> but it does include everything out of the box to be a web server

Sure, and so do plenty of minimal linux distros, and if you use the same metrics and config as OpenBSD then they'll have a similar security track record.

And honestly, Linux with one of the RBAC solutions puts OpenBSD's security to shame.

Do yourself a favor and watch the CCC talk someone else linked in the thread.

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#115

Post by daneel_w »

DEADMINCE wrote: post #100
daneel_w wrote: post #78

Earlier quoted context omitted.

Wouldn't a good systematic evaluation need (or at least benefit from) a few actual working exploits/PoCs? I keep asking this as a long-time OpenBSD user who is genuinely interested in seeing it done, but so far everyone who has said "it's flawed" also reserved themselves the convenience of not having to prove their point in a practical sense.

> Wouldn't a good systematic evaluation need (or at least benefit from) a few actual working exploits/PoCs? Sure, see any of the previous exploits for sshd, or any other software shipped in the OpenBSD default install. > I keep asking this as a long-time OpenBSD user who is genuinely interested in seeing it done, but so far everyone who has said "it's flawed" also reserved themselves the convenience of not having to…

> Sure, see any of the previous exploits for sshd, or any other software shipped in the OpenBSD default install.

Would you like to point to one that successfully utilizes a weakness in OpenBSD itself, which is the topic and implied statement of the video, rather than a weakness in some application running under the superuser?

Just to underline, I'm not interested in discussing the hows and whys of containing arbitrary applications where one or more portions are running under euid 0. I'm interested in seeing OpenBSD successfully attacked by an unprivileged process/user.

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#116

Post by noname120 »

growse wrote: post #64
TacticalCoder wrote: post #62

And who was notoriously not exploitable? The ones hiding sshd behind port knocks. And fail2ban: would work too. And a restrictive firewall: would help too. I don't use port-knocking but I really just don't get all those saying: "It's security theater" . We had not one but two major OpenSSH "near fiasco" (this RCE and the xz lib thing) that were both rendered unusable for attackers by using port knocking. To me port-k…

What benefits does port knocking give over and above a simple VPN? They're both additional layers of authentication, except a VPN seems much more rigorous and brings potentially other benefits. In a world where tailscale etc. have made quality VPNs trivial to implement, why would I both with port knocking?

Port-knocking is way simpler and relies on extremely basic network primitives. As such the attack surface is considerably smaller than OpenSSH or OpenVPN and their authentication mechanisms.

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#117

Post by ttul »

TLDR: this vulnerability does appear to allow an attacker to potentially gain remote root access on vulnerable Linux systems running OpenSSH, with some important caveats:

1. It affects OpenSSH versions 8.5p1 to 9.7p1 on glibc-based Linux systems.

2. The exploit is not 100% reliable - it requires winning a race condition.

3. On a modern system (Debian 12.5.0 from 2024), the researchers estimate it takes: - ~3-4 hours on average to win the race condition - ~6-8 hours on average to obtain a remote root shell (due to ASLR)

4. It requires certain conditions: - The system must be using glibc (not other libc implementations) - 100 simultaneous SSH connections must be allowed (MaxStartups setting) - LoginGraceTime must be set to a non-zero value (default is 120 seconds)

5. The researchers demonstrated working exploits on i386 systems. They believe it's likely exploitable on amd64 systems as well, but hadn't completed that work yet.

6. It's been patched in OpenSSH 9.8p1 released in June 2024.

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#119

Post by fmbb »

OJFord wrote: post #75
fmbb wrote: post #72

Earlier quoted context omitted.

“async-signal-safer” Just this morning was the first time I read the words MT-Safe, AS-Safe, AC-Safe. But I did not know there were “safer” functions as well. Is there also a “safest” syslog?

For a word like 'safe', or at least in CS, I would assume that the 'safe' one actually is 'safest'; that 'safer' is ehh it's not safe but it's an improvement on the unsafe one. It's saf er .

I’m would assume the same. Hence my question.

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#120

Post by mmsc »

DEADMINCE wrote: post #97
mmsc wrote: post #68

Earlier quoted context omitted.

How is it not? If fail2ban isn't going to blocklist localhost, then it isn't a mitigation for this vulnerability because RCE implies LPE.

People are generally not trying to get root via an SSH RCE over localhost. That's going to be a pretty small sample of people that applies to. But, sure, in that case fail2ban won't mitigate, but that's pretty damn obviously implied. For 99% of people and situations, it will.

>People are generally not trying to get root via an SSH RCE over localhost. That's going to be a pretty small sample of people that applies to

It's going to apply to the amount of servers that an attacker has low-privileged access (think: www-data) and an unpatched sshd. Attackers don't care if it's an RCE or not: if a public sshd exploit can be used on a system with a Linux version without a public Linux LPE, it will be used. Being local also greatly increases the exploitability.

Then consider the networks where port 22 is blocked from the internet but sshd is running in some internal network (or just locally for some reason).

Post reply on HN