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

I don't have access to an example rule right now but this could be handled with a pf rule with timeouts and max src conns as an interim fix possibly. Seems more feasible than libwrap.

-- 
 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> wrote:
> 
> 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
>