OpenSSH Race condition resulting in potential remote code execution

[sebstefan]

>A critical vulnerability in sshd(8) was present in Portable OpenSSH versions between 8.5p1 and 9.7p1 (inclusive) that may allow arbitrary code execution with root privileges.

FYI that's every version published after 2021-03-03

That's got to be 99% of all linux machines in the world with an ssh daemon running right?

https://www.openssh.com/releasenotes.html

[alright2565]

> Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with ASLR. Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept.

It's pretty bad, but not trivial to exploit, especially since most machines are 64-bit with a larger space for ASLR.

[yjftsjthsd-h]

A surprising number of systems are apparently on an old enough version to be unaffected; ex. RHEL 6-8 aren't vulnerable.

[citrin_ru]

Red Hat 8 (maintenance support until 2029) has openssh-8.0 which is too old to be affected. I suspect other LTS distro may have openssh older 8.5 too. So the number should be below 99%.

[ta1243]

> That's got to be 99% of all linux machines in the world with an ssh daemon running right?

Since 2021? Nah. 90% of my estate is ubuntu 2018 or earlier.

[cedws]

99%… that’s funny :P

[0x1ceb00da]

Using this exploit, connected non root users can gain root access. Multiple user machines are more or less a thing of the past. These days most common use case of ssh is logging in to a remote server you already own with root privileges. So most of the users are unaffected by this exploit.

[ggeorg]

Sorry, duplicate of https://news.ycombinator.com/item?id=40843778

[ricc]

I do like the headline of this post better though...

[ggeorg]

We discovered a vulnerability (a signal handler race condition) in OpenSSH's server (sshd): if a client does not authenticate within LoginGraceTime seconds (120 by default, 600 in old OpenSSH versions), then sshd's SIGALRM handler is called asynchronously, but this signal handler calls various functions that are not async-signal-safe (for example, syslog()). This race condition affects sshd in its default configuration.

So SIGALRM because of the timer firing?

Out of curiosity... any rust sshd implementations? I found libraries, but no plug&play replacement for openssh?

[alberth]

> Only two remote holes in the default install, in a heck of a long time!

As someone who doesn't know this kind of stuff well, will this cause OpenBSD to have to update the statement above?

https://www.openbsd.org

EDIT:

TFA says:

> OpenBSD is not vulnerable.

[rany_]

OpenBSD isn't vulnerable, from https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion....:

> 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.

[withinboredom]

We have to use this exploit to update a critical raspberry pi that nobody seems to have keys to...

[txdv]

I this exploitable for all architectures? For some reason I am under the impression that its only for x86