Researchers at the Qualys Threat Research Unit (TRU) have unearthed discovered a critical security flaw in OpenSSH's server (sshd) in glibc-based Linux systems.
The full write-up can be found here and should be fairly readable for users of this forum.
Some quotes that I thought were interesting:
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.
So 64-bit systems seem to be a bit more resistant to this it seems? But I can’t be completely sure given how much I’ve read about this yet.
This vulnerability is exploitable remotely on glibc-based Linux systems,
where syslog() itself calls async-signal-unsafe functions (for example,
malloc() and free()): an unauthenticated remote code execution as root,
because it affects sshd’s privileged code, which is not sandboxed and
runs with full privileges. 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.
It seems that non glibc-based systems also could be vulnerable, but they have not yet tried to demonstrate it yet (or have tried and not been successful).
Yeah they were experimenting with 64bit exploitation when this signal handler got some focus regarding a (likely related) deadlock so they rushed to disclose their findings to the project to minimise the possibility of having eyes on this vulnerability
The full write-up can be found here and should be fairly readable for users of this forum.
Some quotes that I thought were interesting:
So 64-bit systems seem to be a bit more resistant to this it seems? But I can’t be completely sure given how much I’ve read about this yet.
It seems that non glibc-based systems also could be vulnerable, but they have not yet tried to demonstrate it yet (or have tried and not been successful).
And OpenBSD wins again it seems.
Yeah they were experimenting with 64bit exploitation when this signal handler got some focus regarding a (likely related) deadlock so they rushed to disclose their findings to the project to minimise the possibility of having eyes on this vulnerability