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

51–60 of 347 posts

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

#51

Post by Piskvorrr »

ale42 wrote: post #32
megous wrote: post #2

In our experiments, it takes ~10,000 tries on average to win this race condition, so ~3-4 hours with 100 connections (MaxStartups) accepted per 120 seconds (LoginGraceTime). Ultimately, it takes ~6-8 hours on average to obtain a remote root shell, because we can only guess the glibc's address correctly half of the time (because of ASLR). MaxStartups default is 10

Such an amount of connections should anyway trigger all possible logging & IDS systems, right?

It should trigger fail2ban, that's for sure.

Alerting is useless, with the volume of automated exploits attempted.

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

#52

Post by udev4096 »

mmsc wrote: post #36
letters90 wrote: post #14

> In our experiments, it takes ~10,000 tries on average to win this race condition, so ~3-4 hours with 100 connections (MaxStartups) accepted per 120 seconds (LoginGraceTime). Ultimately, it takes ~6-8 hours on average to obtain a remote root shell, because we can only guess the glibc's address correctly half of the time (because of ASLR). Mitigate by using fail2ban? Nice to see that Ubuntu isn't affected at all

>Mitigate by using fail2ban? In theory, this could be used (much quicker than the mentioned days/weeks) to get local privilege escalation to root, if you already have some type of shell on the system already. I would assume that fail2ban doesn't block localhost.

How is local privilege escalation relevant here? Fail2ban should be able to block the RCE

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

#54

Post by marcus0x62 »

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

Connection reset by 192.168.1.254 port 22

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

#55

Post by theandrewbailey »

0x0 wrote: post #4

Patch out for Debian 12; Debian 11 not affected. https://security-tracker.debian.org/tracker/CVE-2024-6387

Just ran an apt update and upgrade on my Debian 12 server. OpenSSH packages were the only ones upgraded.

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

#56

Post by ZiiS »

cyberpunk wrote: post #47
j16sdiz wrote: post #45

Now, how many remote exploit do we have in openbsd?

No more than before this; openbsd is not vulnerable to this exploit due to a different syslog() implementation.

Worth being explicit here. The OpenBSD syslog is not just 'different' enough that it was luckily uneffected. It was intentionally designed to avoid this situation more than 20 years ago.

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

#57

Post by fulafel »

cyberpunk wrote: post #47
j16sdiz wrote: post #45

Now, how many remote exploit do we have in openbsd?

No more than before this; openbsd is not vulnerable to this exploit due to a different syslog() implementation.

Also there's no publicly known exploit for this one yet even for Linux. The advisory says Qualys put exploit development on hold to coordinate the fix.

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

#58

Post by qhwudbebd »

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 lock. The {d,sn,vsn}printf() calls there don't allocate in musl, although they might in glibc. Have I missed anything here?

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

#59

Post by apache101 »

nj5rq wrote: post #48

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. Saving the day once again.

Theo and team way ahead of their time like always.

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

#60

Post by yjftsjthsd-h »

> Exploitation on non-glibc systems is conceivable but has not been examined.

( https://www.openssh.com/txt/release-9.8 )

Darn - here I was hoping Alpine was properly immune, but it sounds more like "nobody's checked if it works on musl" at this point.

Post reply on HN