Today, Qualys' Threat Research Unit published another stellar paper: RCE in OpenSSH's server, on glibc-based Linux systems, nicknamed regreSSHion, aka CVE-2024-6387. Since I'm running Alpine Linux, which is using the musl libc, I was curious about the impact there. Fortunately, it boils down to a deadlock at worse:
- Its syslog implementation doesn't
(sub)call async-signal-unsafe functions (see the callgraph here), nor dynamically allocates memory.
Interestingly, string-formatting functions like
(v)snprintfdon't allocate memory by design, to prevent them from failing under memory pressure. Thanks to its small sizeDue to various factors (thanks to minipli for pointing it out), it's not affected by ALSRn't, making the exploitation harder, should it be possible in the first place.- The heap allocator might be a bit more annoying to exploit, due to its security-oriented design.
- The
FILE-based exploitation technique chosen by Qualys looks a tad easier on musl than on glibc, but given the above points and the fact that there is no handyFILEto corrupt, it's a non-issue.
This analysis was confirmed on mastodon:
OpenSSH sshd on musl-based systems is not vulnerable to RCE via CVE-2024-6387 (regreSSHion).
This is because we do not use localtime in log timestamps and do not use dynamic allocation (because it could fail under memory pressure) for printf formatting.
While the sshd bug is UB (AS-unsafe syslog call from signal context), very deliberate decisions we made for other good reasons reduced the potential impact to deadlock taking a lock.