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?
It's pretty bad, but not trivial to exploit, especially since most machines are 64-bit with a larger space for ASLR.
Since 2021? Nah. 90% of my estate is ubuntu 2018 or earlier.
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.
So SIGALRM because of the timer firing?
Out of curiosity... any rust sshd implementations? I found libraries, but no plug&play replacement for openssh?
As someone who doesn't know this kind of stuff well, will this cause OpenBSD to have to update the statement above?
EDIT:
TFA says:
> OpenBSD is not vulnerable.
> 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.
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.
