5 ms·
OpenSSH Race condition resulting in potential remote code execution
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- ggeorg 2y agoSorry, duplicate of https://news.ycombinator.com/item?id=40843778 https://news.ycombinator.com/item?id=40843778
- sebstefan 2y ago>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 https://www.openssh.com/releasenotes.html
- cedws 2y ago99%… that’s funny :P
- 0x1ceb00da 2y agoUsing 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.
- tgv 2y agoI don't think it's best practice to give root privilege to a login account.
- Fire-Dragon-DoL 2y agoWhat do you give it to?
- tgv 2y agoTo 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.
- bheadmaster 2y ago> 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.
- withinboredom 2y agoI have a script that looks at your github org/team and generates/updates users on-demand then lets you connect. The script is pretty straightforward, see AuthorizedKeysCommand and https://github.com/{$user}.keys https://github.com/{$user}.keys
- ta1243 2y agoCertainly, but in my org they're trusted with sudo access (which gets logged to syslog).
- citrin_ru 2y agoRed 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%.
- alright2565 2y ago> 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 2y agoA surprising number of systems are apparently on an old enough version to be unaffected; ex. RHEL 6-8 aren't vulnerable.
- ta1243 2y ago> 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.
- withinboredom 2y agoWe have to use this exploit to update a critical raspberry pi that nobody seems to have keys to...
- txdv 2y agoI this exploitable for all architectures? For some reason I am under the impression that its only for x86
- rany_ 2y agoThey only made a POC for x86 but it doesn't mean that it doesn't work on other architectures.
- ggeorg 2y agoFrom the qualys advisory (https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt 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.
- yjftsjthsd-h 2y agoPer https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt 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.
- alberth 2y ago> 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 https://www.openbsd.org EDIT: TFA says: > OpenBSD is not vulnerable.
- rany_ 2y agoOpenBSD isn't vulnerable, from https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt 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.
- ggeorg 2y agoWe 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?