From nobody Mon Jul 01 15:16:42 2024 X-Original-To: freebsd-security@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WCV5V2Ry8z5P6qZ for ; Mon, 01 Jul 2024 15:17:18 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WCV5T3FHTz44cZ for ; Mon, 1 Jul 2024 15:17:17 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Authentication-Results: mx1.freebsd.org; none Received: by mail-qk1-x72d.google.com with SMTP id af79cd13be357-79c0b1eb94dso209216285a.1 for ; Mon, 01 Jul 2024 08:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=net; t=1719847034; x=1720451834; darn=freebsd.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=nD+S4m2zx94MNW9SCMKmB+cO3kWlM+Ai6+YfxxF8+XA=; b=smaGNyjok5HMZG/t+tHx31XPnvSZW/maE3VUazWvpI1707RukAPkXoJjzBwvmY7UmY YxrrPjUACrxO4OvPAEdPtXc+jolSh+lGFM84Cj8KdaREpubjR5X+X9cGG1ZuvP7WS5Cy PT445k4yN5vLpHQBU1kn7Yx/sBlxh72WV6Bt0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719847034; x=1720451834; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=nD+S4m2zx94MNW9SCMKmB+cO3kWlM+Ai6+YfxxF8+XA=; b=pclPsRqUcIRPMv6VkDr7TnA1vlGHoYcGUt9U0SnGvbs4GtDgC7RJDJ4ibcwXI9qi+U P5PiSRGRJqkDviotqPX5fj2o+EcUI6gKz6MB3q+gcDup4bE4ESeaLwNrH3f+6PucX3Iv KCIVPbRgVl+CQf7RIhIsfqxLtp9mFU+l7jfX1Z3GycmMndrMH/OIZYh1TW4xBJFYLkPk M347JyMQw8MR7Ahk/Tz34JAl2hnVKtmsiYXHiBQHGb6m6pNh84XroAthJkWrv5KUrfDj xxS4xIE8fwo60ExLZ5/cvqF/RXv9MjJTvXRz0nSEo5/3ekD8tQYIEdtifE3l28QE2Bas y3ew== X-Gm-Message-State: AOJu0Yzw2J2lwuserWDMcXG+/m25tHmBCACo/P3rhZpGlrsTVzRYFDBA 5vLluyvUZ59iJc+TpWGJSgSJxCFWyHPlS4EG8r6oDKbq8rCdZHIQw+oNvBKBdQVJ4YVSJuT5aXO j X-Google-Smtp-Source: AGHT+IHXM6c/dwQA1GVy3aUwBVXchEbTOURROTFSNWbGcFlkLkEgGmdn4al4gIahICmS+CL9Yc77ZA== X-Received: by 2002:a05:620a:4625:b0:79d:7e9d:f4b with SMTP id af79cd13be357-79d7e9d123dmr884380385a.44.1719847034057; Mon, 01 Jul 2024 08:17:14 -0700 (PDT) Received: from smtpclient.apple ([2600:1008:b190:3a61:588d:f683:7d41:334d]) by smtp.gmail.com with ESMTPSA id af79cd13be357-79d692eabe8sm355800885a.72.2024.07.01.08.17.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jul 2024 08:17:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "J. Hellenthal" List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-security@freebsd.org Sender: owner-freebsd-security@FreeBSD.org Mime-Version: 1.0 (1.0) Subject: Re: FreeBSD Security Advisory FreeBSD-SA-24:04.openssh Date: Mon, 1 Jul 2024 10:16:42 -0500 Message-Id: <3929C43B-33C1-4DCC-B778-2C80927DD2F6@dataix.net> References: <44522737-qr68-q1n2-rs8o-7o75329982o0@yvfgf.mnoonqbm.arg> Cc: freebsd-security@freebsd.org In-Reply-To: <44522737-qr68-q1n2-rs8o-7o75329982o0@yvfgf.mnoonqbm.arg> To: "Bjoern A. Zeeb" X-Mailer: iPhone Mail (22A5297f) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WCV5T3FHTz44cZ 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 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