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