[deleted]
OpenSSH Race condition resulting in potential remote code execution
21–29 of 29 posts
Re: OpenSSH Race condition resulting in potential remote code execution
#22Earlier quoted context omitted.
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.
> These days most common use case of ssh is logging in to a remote server you already own with root privileges I only see this in relatively small and "young" teams. In any bigger organization I've worked in, a new user is created for each person who uses the machine.
Certainly, but in my org they're trusted with sudo access (which gets logged to syslog).
Re: OpenSSH Race condition resulting in potential remote code execution
#23Earlier quoted context omitted.
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.
Are you sure? The text implies that the unsafe path is getting interrupted while parsing a DSA key, which presumably occurs before authentication?
Indeed, remote root is possible.
https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion....
Re: OpenSSH Race condition resulting in potential remote code execution
#24We 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?
Re: OpenSSH Race condition resulting in potential remote code execution
#25We have to use this exploit to update a critical raspberry pi that nobody seems to have keys to...
I this exploitable for all architectures? For some reason I am under the impression that its only for x86
They only made a POC for x86 but it doesn't mean that it doesn't work on other architectures.
Re: OpenSSH Race condition resulting in potential remote code execution
#26We have to use this exploit to update a critical raspberry pi that nobody seems to have keys to...
I this exploitable for all architectures? For some reason I am under the impression that its only for x86
From the qualys advisory (https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion....):
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.
It is a race condition in a signal handler. The behaviour depends on the implementation of various standard library functions on the target system (syslog, malloc). This may very well be exploitable on other architectures (and systems). Apparently it is non-trivial to trigger. But it is possibly remote code execution with root permissions. Definetely nobody wants this in sshd.
Re: OpenSSH Race condition resulting in potential remote code execution
#27We have to use this exploit to update a critical raspberry pi that nobody seems to have keys to...
I this exploitable for all architectures? For some reason I am under the impression that its only for x86
Per https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.... they developed the exploit on Debian and Ubuntu on i386, but I don't believe there's any reason to think that it wouldn't work on other architectures. There are some things that suggest to my non-expert reading that it's harder to exploit on 64-bit architectures, and other libc implementations may be immune, but it wouldn't surprise me at all if Raspberry Pi OS (AKA Debian with some modifications) on a Pi was 32-bit and vulnerable.
Re: OpenSSH Race condition resulting in potential remote code execution
#28Earlier quoted context omitted.
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.
I don't think it's best practice to give root privilege to a login account.
What do you give it to?
Re: OpenSSH Race condition resulting in potential remote code execution
#29Earlier quoted context omitted.
I don't think it's best practice to give root privilege to a login account.
What do you give it to?
To root, and you must have a sudo password to get it. It stops both hackers and colleagues who need access to the servers, but can't be trusted with root privileges.