Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 Jul 2024 01:32:32 +0000
From: Qualys Security Advisory <qsa@...lys.com>
To: Yves-Alexis Perez <corsac@...ian.org>
CC: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: Re: CVE-2024-6387: RCE in OpenSSH's server, on
 glibc-based Linux systems

Hi Yves-Alexis, all,

On Wed, Jul 03, 2024 at 10:54:30PM +0200, Yves-Alexis Perez wrote:
> use `-e` on sshd command-line as a mitigation measure.

An interesting idea!

> 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-
> signal-safe).

We also agree: the glibc's snprintf() only calls malloc functions if the
format string specifies positional parameters or floating points, which
is not the case in sshd's SIGALRM handler.

We double-checked this on Debian 12.5.0 and confirmed that the SIGALRM
handler does not call any malloc function anymore if "-e" is used.

> What are you thoughts on this mitigation?

Perhaps surprisingly (given the above) we advise against this mitigation
in the general case: unlike the "LoginGraceTime 0" mitigation, this "-e"
mitigation still calls the SIGALRM handler, which has a long and complex
history in sshd, so there is no guarantee that this mitigation is also
safe for other distributions or versions of sshd.

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

Thank you very much for your kind words! With best regards,

-- 
the Qualys Security Advisory team

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.