Notes on regreSSHion on musl
Mon 01 July 2024 — download

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)snprintf don't allocate memory by design, to prevent them from failing under memory pressure.
  • Thanks to its small size Due 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 handy FILE to 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.