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

251–260 of 347 posts

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

#251

Post by hsbauauvhabzb »

ttul wrote: post #117

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…

I’m not sure how many Linux users would know if they’re using glibc or another variation. Is there a list?

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

#252

Post by DEADMINCE »

yjftsjthsd-h wrote: post #219
DEADMINCE wrote: post #132

Earlier quoted context omitted.

Any vulns in any package in OpenBSD's package repositories that they audited should count as a vuln against OpenBSD itself. If OpenBSD users installed it through OpenBSD repositories and are running it will they be affected? Yes? Then it counts against the system itself.

I'm not sure that's fair; was log4j a vulnerability in Ubuntu itself? How about libwebp ( https://news.ycombinator.com/item?id=37657746 )?

> I'm not sure that's fair;

It's the way most distros handled security vulnerabilities, though. Without looking, I'm certain Ubuntu has a security advisory for that vulnerability.

So I agree it might not be fair on the face of it or if doing a technical analysis or something, but if you want to compare OpenBSD security to other Linux distros by vulnerability count, (and so many who don't know better do), then vulnerabilities should be measured in the same way across both systems.

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

#253

Post by usr1106 »

loeg wrote: post #213
FiloSottile wrote: post #20

Interestingly, the RCE fix was "smuggled" in public almost a month ago. When PerSourcePenalties are enabled, sshd(8) will monitor the exit status of its child pre-auth session processes. Through the exit status, it can observe situations where the session did not authenticate as expected. These conditions include when the client repeatedly attempted authentication unsucessfully (possibly indicating an attack against…

Has this fix been pushed to / pulled by distributions yet?

SUSE has the fixes under testing. I assume you could install them directly from OBS. I have not tried because I have no exposed system. https://www.suse.com/security/cve/CVE-2024-6387.html

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

#254

Post by CaliforniaKarl »

loeg wrote: post #237
loeg wrote: post #213

Earlier quoted context omitted.

Has this fix been pushed to / pulled by distributions yet?

Fedora: not yet. https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2024-6387 (tracking task) https://bugzilla.redhat.com/show_bug.cgi?id=2294905 (Fedora 39 issue)

And https://bugzilla.redhat.com/show_bug.cgi?id=2294904 (Fedora 40 issue)

EL 9 is also affected, but not yet released. The tracking task will update as things move along.

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

#255

Post by CaliforniaKarl »

loeg wrote: post #213
FiloSottile wrote: post #20

Interestingly, the RCE fix was "smuggled" in public almost a month ago. When PerSourcePenalties are enabled, sshd(8) will monitor the exit status of its child pre-auth session processes. Through the exit status, it can observe situations where the session did not authenticate as expected. These conditions include when the client repeatedly attempted authentication unsucessfully (possibly indicating an attack against…

Has this fix been pushed to / pulled by distributions yet?

Ubuntu's also got patches out for 22.04 LTS, 23.10, and 24.04 LTS. See https://ubuntu.com/security/notices/USN-6859-1.

Amazon Linux 2023 is affected; Amazon Linux 1 & 2 are not. Status updates will be posted to https://explore.alas.aws.amazon.com/CVE-2024-6387.html

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

#256

Post by arjvik »

hsbauauvhabzb wrote: post #251
ttul wrote: post #117

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…

I’m not sure how many Linux users would know if they’re using glibc or another variation. Is there a list?

If you don't know, you're likely running glibc. Distros that use musl do so intentionally (alpine, etc.)

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

#257

Post by arjvik »

ttul wrote: post #117

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…

Why is it that the ASLR only adds 1 bit of randomness (doubling the time it takes to win the attack)?

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

#258

Post by pornel »

ekimekim wrote: post #244
pornel wrote: post #242

Earlier quoted context omitted.

There are, but safety of their implementation is not checked by the language. Rust doesn't have an effect system nor a similar facility to flag what code is not signal-handler-safe. A Rust implementation could just as likely call something incompatible. Rust has many useful guarantees, and is a significant improvement over C in most cases, but let's be precise about what Rust can and can't do.

> Rust doesn't have an effect system nor a similar facility to flag what code is not signal-handler-safe. My understanding is that a sound implementation of signal handling in Rust will require the signal handler to be Send, requiring it only has access to shared data that is Sync (safe to share between threads). I guess thread-safe does not nessecarily imply signal-safe, though. And of course you could still call to…

Signal handlers are not threads. Rust doesn't have anything that expresses the special extremely restrictive requirements of signal handlers.

A safe-Rust thread-safe Send+Sync function is allowed to call `format!()`, or `Box::new`, or drop a `Vec`, all of which will directly cause the exact same vulnerability as in SSH.

There is nothing in Rust that can say "you can't drop a Vec", and there are no tools that will let you find out whether any function you call may do it. Rust can't even statically prove that panics won't happen. Rust's panic implementation performs heap allocations, so any Rust construct that can panic is super unsafe in signal handlers.

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

#259

Post by ranger_danger »

rfmoz wrote: post #15

From the report: > Finally, if sshd cannot be updated or recompiled, this signal handler race condition can be fixed by simply setting LoginGraceTime to 0 in the configuration file. This makes sshd vulnerable to a denial of service (the exhaustion of all MaxStartups connections), but it makes it safe from the remote code execution presented in this advisory. Setting 'LoginGraceTime 0' in sshd_config file seems to mit…

Perhaps a more realistic workaround would be simply to make the grace time (or inversely, max connections) long enough that the chances of a successful attack are far too long in the future to be worth attempting.

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

#260

Post by bigiain »

devit wrote: post #248
jamilbk wrote: post #217

From the diff introducing the bug [1], the issue according to the analysis is that the function was refactored from this: void sigdie(const char *fmt,...) { #ifdef DO_LOG_SAFE_IN_SIGHAND va_list args; va_start(args, fmt); do_log(SYSLOG_LEVEL_FATAL, fmt, args); va_end(args); #endif _exit(1); } to this: void sshsigdie(const char *file, const char *func, int line, const char *fmt, ...) { va_list args; va_start(args, fmt…

One of these: 1. Using a proper programming language that doesn't allow you to setup arbitrary functions as signal handlers (since that's obviously unsafe on common libcs...) - e.g. you can't do that in safe Rust, or Java, etc. 2. Using a well-implemented libc that doesn't cause memory corruption when calling async-signal-unsafe functions but only deadlocks (this is very easy to achieve by treating code running in si…

This is all great thinking.

Except for those of us who live in a world where most of their OS and utilities and libraries were originally written decades before Rust existed, and often even before Java existed. And where "legacy" C code pretty much underpins everything running on the public internet and which you need to connect to.

There's a very real risk that reimplementing every piece of code on a modern internet connected server in exciting new "safe" languages and libc-type things - by a bunch of "modern" programmers who do not have the learning experience of decades worth of mistakes - will end up with not just new implementation of old and fixed bugs and security problems, but also with new implementations that are incompatible in strange and hard to debug ways with every existing piece of software that uses SSH protocols as they are deployed in the field.

I, for one, and not going to install and put into production version 1.0 of some new OpenSSH replacement written in Rust out Go or Java, which has a non zero chance of strange edge case bugs that are different when connecting to SSH on different Linux/BSD/Windows distros or versions, across different cpu architectures, and probably have subtly different bugs when connecting to different cloud hyperscalers.

Post reply on HN