On Mon, 1 Jul 2024, FreeBSD Security Advisories wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

=============================================================================
FreeBSD-SA-24:04.openssh                                    Security Advisory
                                                         The FreeBSD Project

Topic:          OpenSSH pre-authentication remote code execution

Category:       contrib
Module:         openssh
Announced:      2024-07-01
Credits:        Qualys Threat Research Unit (TRU)
Affects:        All supported versions of FreeBSD.
[..]
II.  Problem Description

A signal handler in sshd(8) calls a function that is not async-signal-safe.
The signal handler is invoked when a client does not authenticate within the
LoginGraceTime seconds (120 by default).  This signal handler executes in the
context of the sshd(8)'s privileged code, which is not sandboxed and runs
with full root privileges.

This issue is a regression of CVE-2006-5051 originally reported by Mark Dowd
and accidentally reintroduced in OpenSSH 8.5p1.

III. Impact

As a result of calling functions that are not async-signal-safe in the
privileged sshd(8) context, a race condition exists that a determined
attacker may be able to exploit to allow an unauthenticated remote code
execution as root.

IV.  Workaround

If sshd(8) cannot be updated, this signal handler race condition can be
mitigated by setting LoginGraceTime to 0 in /etc/ssh/sshd_config and
restarting sshd(8).  This makes sshd(8) vulnerable to a denial of service
(the exhaustion of all MaxStartups connections), but makes it safe from the
remote code execution presented in this advisory.

Can this code path still be exploited in FreeBSD if libwrap/hosts_access
is used denying connections (at least from untrusted sources)?

A quick look seems to show that LIBWRAP checking happens before the signal
handler is setup and the bug needs connections to be accepted?

--
Bjoern A. Zeeb                                                     r15:7

Reply via email to