Date: Mon, 1 Jul 2024 10:16:42 -0500 From: "J. Hellenthal" <jhellenthal@dataix.net> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-24:04.openssh Message-ID: <3929C43B-33C1-4DCC-B778-2C80927DD2F6@dataix.net> In-Reply-To: <44522737-qr68-q1n2-rs8o-7o75329982o0@yvfgf.mnoonqbm.arg> References: <44522737-qr68-q1n2-rs8o-7o75329982o0@yvfgf.mnoonqbm.arg>
next in thread | previous in thread | raw e-mail | index | archive | help
I don't have access to an example rule right now but this could be handled w= ith a pf rule with timeouts and max src conns as an interim fix possibly. Se= ems more feasible than libwrap. --=20 J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a= lot about anticipated traffic volume. > On Jul 1, 2024, at 05:34, Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net> w= rote: >=20 > =EF=BB=BFOn Mon, 1 Jul 2024, FreeBSD Security Advisories wrote: >=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >> FreeBSD-SA-24:04.openssh Security Advi= sory >> The FreeBSD Proje= ct >>=20 >> Topic: OpenSSH pre-authentication remote code execution >>=20 >> Category: contrib >> Module: openssh >> Announced: 2024-07-01 >> Credits: Qualys Threat Research Unit (TRU) >> Affects: All supported versions of FreeBSD. > [..] >> II. Problem Description >>=20 >> A signal handler in sshd(8) calls a function that is not async-signal-saf= e. >> The signal handler is invoked when a client does not authenticate within t= he >> 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. >>=20 >> This issue is a regression of CVE-2006-5051 originally reported by Mark D= owd >> and accidentally reintroduced in OpenSSH 8.5p1. >>=20 >> III. Impact >>=20 >> 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. >>=20 >> IV. Workaround >>=20 >> 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 t= he >> remote code execution presented in this advisory. >=20 > Can this code path still be exploited in FreeBSD if libwrap/hosts_access > is used denying connections (at least from untrusted sources)? >=20 > A quick look seems to show that LIBWRAP checking happens before the signal= > handler is setup and the bug needs connections to be accepted? >=20 > -- > Bjoern A. Zeeb r15:7 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3929C43B-33C1-4DCC-B778-2C80927DD2F6>