Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 1 Jul 2024 17:36:48 +0200
From: jvoisin <>
Subject: Re: CVE-2024-6387: RCE in OpenSSH's server, on
 glibc-based Linux systems

> 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.

I gave a cursory look at the musl libc ( with the
help of the lovely #musl people, and it doesn't seem to be affected:

- Its syslog implementation ( ) doesn't
seem to (sub)call async-signal-unsafe functions.
- Thanks to its small size, it's not affected by ALSRn't.

So the worse that can happen might be a deadlock. Which is good news,
since the FILE-based exploitation technique looks easier on musl than on

Moreover, as said by the project

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.

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.