Re: FreeBSD Security Advisory FreeBSD-SA-24:04.openssh

From: Bjoern A. Zeeb <bzeeb-lists_at_lists.zabbadoz.net>
Date: Mon, 01 Jul 2024 10:34:00 UTC
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