Re: FreeBSD Security Advisory FreeBSD-SA-24:04.openssh
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