Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 03 Jul 2024 22:54:30 +0200
From: Yves-Alexis Perez <>
Subject: Re: CVE-2024-6387: RCE in OpenSSH's server, on
 glibc-based Linux systems

Hash: SHA256

On Mon, 2024-07-01 at 08:40 +0000, Qualys Security Advisory wrote:
> Finally, if sshd cannot be updated or recompiled, this signal handler
> race condition can be fixed by simply setting LoginGraceTime to 0 in the
> configuration file. This makes sshd vulnerable to a denial of service
> (the exhaustion of all MaxStartups connections), but it makes it safe
> from the remote code execution presented in this advisory.


thanks Qualys for the outstanding research and detailed report (as always).

On Mastodon Hector Marcan also proposed
( to
use `-e` on sshd command-line as a mitigation measure.

Copying the whole text from the first post for archiving purpose on the list:

OpenSSH CVE-2024-6387 mitigation (on Fedora):

echo 'OPTIONS=-e' | sudo tee -a /etc/sysconfig/sshd && sudo systemctl restart

I have no idea why Qualys didn't mention this. The only non-async-safe
function called by the vulnerable signal handler is syslog(). So just turn off
syslog and log to stderr. On systemd distros, this still ends up in the
journal anyway, so you lose nothing.

I confirmed that the message at the root of the issue is logged to stderr and
not syslog with this option:

[pid 638194] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
[pid 638194] getpgid(0)                 = 638194
[pid 638194] getpid()                   = 638194
[pid 638194] rt_sigaction(SIGTERM, {sa_handler=SIG_IGN, sa_mask=~[RTMIN RT_1],
sa_flags=SA_RESTART}, {sa_handler=SIG_DFL, sa_mask=~[KILL STOP RTMIN RT_1],
sa_flags=SA_RESTART}, 8) = 0
[pid 638194] kill(0, SIGTERM)           = 0
[pid 638194] getpid()                   = 638194
[pid 638194] write(2, "Timeout before authentication for port
37734\r\n", 60) = 60
[pid 638194] exit_group(1)              = ?
[pid 638194] +++ exited with 1 +++

Edit: The problem code still calls snprintf() which on-paper is still unsafe.
However, it does this a bunch of times anyway in multiple code paths, and
Qualys didn't mention anything about it. A quick look through glibc code
suggests that snprintf() only does unsafe things (allocate memory) if you
format floats, which obviously ssh does not.

I agree with Hector that at first sight the `snprintf()` call look OK on glibc
(no dynamic memory allocation or complicated handling that I could spot
either), and the write to stderr is done using write(2) (which is async-

The change isn't totally agnostic even on systemd/journald systems because
you'll lose some log metadata (facility and loglevel) and it might depend on
some local syslog configuration, but if one can't update it might be better
than turning into a DoS (or totally losing logs by setting LogLevel to Quiet).

On Debian based systems you can put `-e` in SSHD_OPTS in /etc/default/ssh.

What are you thoughts on this mitigation?

- -- 


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.