From nobody Sat Feb 4 02:51:38 2023 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 4P7xqy2Rg7z3kYr1 for ; Sat, 4 Feb 2023 02:51:42 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P7xqx3QFbz45JG for ; Sat, 4 Feb 2023 02:51:41 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com; dmarc=none Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id O01SpiXMZc9C4O8eSpNwfK; Sat, 04 Feb 2023 02:51:40 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id O8eRpToex3fOSO8eSpBKnD; Sat, 04 Feb 2023 02:51:40 +0000 X-Authority-Analysis: v=2.4 cv=J8G5USrS c=1 sm=1 tr=0 ts=63ddc83c a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=m04uMKEZRckA:10 a=auHYCxwYAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=ncAhmZ006X6_3sS83AwA:9 a=CjuIK1q_8ugA:10 a=67XU6oJk2Lrwzah0vfu5:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id D63D23AC; Fri, 3 Feb 2023 18:51:38 -0800 (PST) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 974A212F; Fri, 3 Feb 2023 18:51:38 -0800 (PST) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Sambuddho Chakravarty cc: freebsd-security@freebsd.org Subject: Re: help regarding IP address spoofing (when using nmap) In-reply-to: References: Comments: In-reply-to Sambuddho Chakravarty message dated "Thu, 02 Feb 2023 16:19:57 +0530." List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Feb 2023 18:51:38 -0800 Message-Id: <20230204025138.974A212F@slippy.cwsent.com> X-CMAE-Envelope: MS4xfKsYgPwkX/Us1hM3SAUNN0d70IZARWOkTepmH8DG5kQ7Sjs7HwRdaX7rGHBUlSMUnWcFLT6hvaM0r8XpBFKijf7iYckMT6910/yHySJ6gWGojXcz4s7J pEXdvOIbrWd/wVmjXK1jTOUpqmmVvAMDCT8i6QPvV/vPpSYuaHKYDY4EAgFduGihKp7OO5TAz0H5IAWOjpRgwJ2xuf7QkpNUiU5EcUge3WucdpxjWvZPAspm fRadrYiptK2VSlvDjOuAVQ== X-Spamd-Result: default: False [-1.70 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.32:from]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-security@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[3.97.99.32:from]; RCVD_TLS_LAST(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com] X-Rspamd-Queue-Id: 4P7xqx3QFbz45JG X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N In message , Sambuddho Chakravarty writes: > --0000000000000384a005f3b55664 > Content-Type: text/plain; charset="UTF-8" > > Hi All > I am a relatively newbie to FreeBSD (earlier was running > Linux). I am running FreeBSD 13.1. > > I am trying to run nmap with source IP address spoofing > (for some academic purposes). It works fine with Linux > but on FreeBSD I get the following error: > > # nmap -e re0 -S 192.168.17.92 -sS 143.110.249.18 -p 8080 -Pn > Starting Nmap 7.93 ( https://nmap.org ) at 2023-02-02 16:04 IST > NSOCK ERROR [0.0170s] mksock_bind_addr(): Bind to 192.168.17.92:0 failed > (IOD #1): Can't assign requested address (49) > NSOCK ERROR [0.0170s] mksock_bind_addr(): Bind to 192.168.17.92:0 failed > (IOD #2): Can't assign requested address (49) I tried the following from my laptop (IP 10.1.1.91) to one of my machines on my network 10.1.1.7. slippy# nmap -e lagg0 -S 192.168.17.92 -sS 10.1.1.7 -p 8080 -Pn Starting Nmap 7.93 ( https://nmap.org ) at 2023-02-03 18:43 PST Nmap scan report for bob (10.1.1.7) Host is up (0.00040s latency). PORT STATE SERVICE 8080/tcp filtered http-proxy MAC Address: xx:xx:xx:xx:xx:xx (NIC manufacturer name was here) Nmap done: 1 IP address (1 host up) scanned in 0.36 seconds slippy# tcpdump showed the following on the target system. 18:43:06.847120 ARP, Request who-has 10.1.1.7 tell 192.168.17.92, length 46 18:43:06.847143 ARP, Reply 10.1.1.7 is-at xx:xx:xx:xx:xx, length 28 18:43:06.880860 IP 192.168.17.92.33262 > 10.1.1.7.8080: Flags [S], seq 1331497492, win 1024, options [mss 1460], length 0 18:43:06.880897 IP 10.1.1.7.8080 > 192.168.17.92.33262: Flags [R.], seq 0, ack 1331497493, win 0, length 0 18:43:06.987099 IP 192.168.17.92.33264 > 10.1.1.7.8080: Flags [S], seq 1331628566, win 1024, options [mss 1460], length 0 18:43:06.987133 IP 10.1.1.7.8080 > 192.168.17.92.33264: Flags [R.], seq 0, ack 1331628567, win 0, length 0 I have nothing listening on port 8080 thus 10.1.1.7 correctly replied with a RST. > > > It works fine without the source spoofing but doesn't when I use > it. I can however use my own machine's source IP address with > the '-S' option. As you can see from above it worked fine here. Were you running it under root or some other account? Was there something else bound to that address? -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Wed Feb 8 07:29:09 2023 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 4PBWqK1zWlz3kqc6 for ; Wed, 8 Feb 2023 07:30:05 +0000 (UTC) (envelope-from doctor@doctor.nl2k.ab.ca) Received: from doctor.nl2k.ab.ca (doctor.nl2k.ab.ca [204.209.81.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PBWqJ34QDz3PGV for ; Wed, 8 Feb 2023 07:30:04 +0000 (UTC) (envelope-from doctor@doctor.nl2k.ab.ca) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of doctor@doctor.nl2k.ab.ca designates 204.209.81.1 as permitted sender) smtp.mailfrom=doctor@doctor.nl2k.ab.ca; dmarc=pass (policy=quarantine) header.from=nl2k.ab.ca Received: from doctor by doctor.nl2k.ab.ca with local (Exim 4.96) (envelope-from ) id 1pPetB-0007Q4-1i for freebsd-security@freebsd.org; Wed, 08 Feb 2023 00:29:09 -0700 Date: Wed, 8 Feb 2023 00:29:09 -0700 From: The Doctor To: freebsd-security@freebsd.org Subject: [openssl@openssl.org: OpenSSL Security Advisory] Message-ID: List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Result: default: False [-1.33 / 15.00]; INTRODUCTION(2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.79)[-0.786]; NEURAL_HAM_MEDIUM(-0.75)[-0.747]; DMARC_POLICY_ALLOW(-0.50)[nl2k.ab.ca,quarantine]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:6171, ipnet:204.209.81.0/24, country:CA]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-security@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4PBWqJ34QDz3PGV X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N Any concerns vis-a-vis FreeBSD? ----- Forwarded message from OpenSSL ----- Date: Tue, 7 Feb 2023 16:32:29 +0000 From: OpenSSL To: openssl-project@openssl.org, OpenSSL User Support ML , OpenSSL Announce ML Subject: OpenSSL Security Advisory -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL Security Advisory [7th February 2023] ============================================= X.400 address type confusion in X.509 GeneralName (CVE-2023-0286) ================================================================= Severity: High There is a type confusion vulnerability relating to X.400 address processing inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING but the public structure definition for GENERAL_NAME incorrectly specified the type of the x400Address field as ASN1_TYPE. This field is subsequently interpreted by the OpenSSL function GENERAL_NAME_cmp as an ASN1_TYPE rather than an ASN1_STRING. When CRL checking is enabled (i.e. the application sets the X509_V_FLAG_CRL_CHECK flag), this vulnerability may allow an attacker to pass arbitrary pointers to a memcmp call, enabling them to read memory contents or enact a denial of service. In most cases, the attack requires the attacker to provide both the certificate chain and CRL, neither of which need to have a valid signature. If the attacker only controls one of these inputs, the other input must already contain an X.400 address as a CRL distribution point, which is uncommon. As such, this vulnerability is most likely to only affect applications which have implemented their own functionality for retrieving CRLs over a network. OpenSSL versions 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.8. OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1t. OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zg (premium support customers only). This issue was reported on 11th January 2023 by David Benjamin (Google). The fix was developed by Hugo Landau. Timing Oracle in RSA Decryption (CVE-2022-4304) =============================================== Severity: Moderate A timing based side channel exists in the OpenSSL RSA Decryption implementation which could be sufficient to recover a plaintext across a network in a Bleichenbacher style attack. To achieve a successful decryption an attacker would have to be able to send a very large number of trial messages for decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5, RSA-OEAP and RSASVE. For example, in a TLS connection, RSA is commonly used by a client to send an encrypted pre-master secret to the server. An attacker that had observed a genuine connection between a client and a server could use this flaw to send trial messages to the server and record the time taken to process them. After a sufficiently large number of messages the attacker could recover the pre-master secret used for the original connection and thus be able to decrypt the application data sent over that connection. OpenSSL 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.8. OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1t. OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zg (premium support customers only). An initial report of a possible timing side channel was made on 14th July 2020 by Hubert Kario (Red Hat). A refined report identifying a specific timing side channel was made on 15th July 2022 by Hubert Kario. The fix was developed by Dmitry Belyavsky (Red Hat) and Hubert Kario. X.509 Name Constraints Read Buffer Overflow (CVE-2022-4203) =========================================================== Severity: Moderate A read buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. The read buffer overrun might result in a crash which could lead to a denial of service attack. In theory it could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext) although we are not aware of any working exploit leading to memory contents disclosure as of the time of release of this advisory. In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects. OpenSSL versions 3.0.0 to 3.0.7 are vulnerable to this issue. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.8. OpenSSL 1.1.1 and 1.0.2 are not affected by this issue. This issue was reported to OpenSSL on 3rd November 2022 by Corey Bonnell from Digicert. The fix was developed by Viktor Dukhovni. Use-after-free following BIO_new_NDEF (CVE-2023-0215) ===================================================== Severity: Moderate The public API function BIO_new_NDEF is a helper function used for streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL to support the SMIME, CMS and PKCS7 streaming capabilities, but may also be called directly by end user applications. The function receives a BIO from the caller, prepends a new BIO_f_asn1 filter BIO onto the front of it to form a BIO chain, and then returns the new head of the BIO chain to the caller. Under certain conditions, for example if a CMS recipient public key is invalid, the new filter BIO is freed and the function returns a NULL result indicating a failure. However, in this case, the BIO chain is not properly cleaned up and the BIO passed by the caller still retains internal pointers to the previously freed filter BIO. If the caller then goes on to call BIO_pop() on the BIO then a use-after-free will occur. This will most likely result in a crash. This scenario occurs directly in the internal function B64_write_ASN1() which may cause BIO_new_NDEF() to be called and will subsequently call BIO_pop() on the BIO. This internal function is in turn called by the public API functions PEM_write_bio_ASN1_stream, PEM_write_bio_CMS_stream, PEM_write_bio_PKCS7_stream, SMIME_write_ASN1, SMIME_write_CMS and SMIME_write_PKCS7. Other public API functions that may be impacted by this include i2d_ASN1_bio_stream, BIO_new_CMS, BIO_new_PKCS7, i2d_CMS_bio_stream and i2d_PKCS7_bio_stream. The OpenSSL cms and smime command line applications are similarly affected. OpenSSL 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.8. OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1t. OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zg (premium support customers only). This issue was reported on 29th November 2022 by Octavio Galland and Marcel B?hme (Max Planck Institute for Security and Privacy). The fix was developed by Viktor Dukhovni and Matt Caswell. Double free after calling PEM_read_bio_ex (CVE-2022-4450) ========================================================= Severity: Moderate The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and decodes the "name" (e.g. "CERTIFICATE"), any header data and the payload data. If the function succeeds then the "name_out", "header" and "data" arguments are populated with pointers to buffers containing the relevant decoded data. The caller is responsible for freeing those buffers. It is possible to construct a PEM file that results in 0 bytes of payload data. In this case PEM_read_bio_ex() will return a failure code but will populate the header argument with a pointer to a buffer that has already been freed. If the caller also frees this buffer then a double free will occur. This will most likely lead to a crash. This could be exploited by an attacker who has the ability to supply malicious PEM files for parsing to achieve a denial of service attack. The functions PEM_read_bio() and PEM_read() are simple wrappers around PEM_read_bio_ex() and therefore these functions are also directly affected. These functions are also called indirectly by a number of other OpenSSL functions including PEM_X509_INFO_read_bio_ex() and SSL_CTX_use_serverinfo_file() which are also vulnerable. Some OpenSSL internal uses of these functions are not vulnerable because the caller does not free the header argument if PEM_read_bio_ex() returns a failure code. These locations include the PEM_read_bio_TYPE() functions as well as the decoders introduced in OpenSSL 3.0. The OpenSSL asn1parse command line application is also impacted by this issue. OpenSSL 3.0 and 1.1.1 are vulnerable to this issue. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.8. OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1t. OpenSSL 1.0.2 is not affected by this issue. This issue was discovered by CarpetFuzz and reported on 8th December 2022 by Dawei Wang. The fix was developed by Kurt Roeckx and Matt Caswell. Invalid pointer dereference in d2i_PKCS7 functions (CVE-2023-0216) ================================================================== Severity: Moderate An invalid pointer dereference on read can be triggered when an application tries to load malformed PKCS7 data with the d2i_PKCS7(), d2i_PKCS7_bio() or d2i_PKCS7_fp() functions. The result of the dereference is an application crash which could lead to a denial of service attack. The TLS implementation in OpenSSL does not call this function however third party applications might call these functions on untrusted data. OpenSSL versions 3.0.0 to 3.0.7 are vulnerable to this issue. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.8. OpenSSL 1.1.1 and 1.0.2 are not affected by this issue. This issue was reported on 27th December 2022 by Marc Sch?nefeld. The fix was developed by Tomas Mraz. NULL dereference validating DSA public key (CVE-2023-0217) ========================================================== Severity: Moderate An invalid pointer dereference on read can be triggered when an application tries to check a malformed DSA public key by the EVP_PKEY_public_check() function. This will most likely lead to an application crash. This function can be called on public keys supplied from untrusted sources which could allow an attacker to cause a denial of service attack. The TLS implementation in OpenSSL does not call this function but applications might call the function if there are additional security requirements imposed by standards such as FIPS 140-3. OpenSSL versions 3.0.0 to 3.0.7 are vulnerable to this issue. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.8. OpenSSL 1.1.1 and 1.0.2 are not affected by this issue. This issue was reported on 27th December 2022 by Kurt Roeckx. The fix was developed by Shane Lontis from Oracle. NULL dereference during PKCS7 data verification (CVE-2023-0401) =============================================================== Severity: Moderate A NULL pointer can be dereferenced when signatures are being verified on PKCS7 signed or signedAndEnveloped data. In case the hash algorithm used for the signature is known to the OpenSSL library but the implementation of the hash algorithm is not available the digest initialization will fail. There is a missing check for the return value from the initialization function which later leads to invalid usage of the digest API most likely leading to a crash. The unavailability of an algorithm can be caused by using FIPS enabled configuration of providers or more commonly by not loading the legacy provider. PKCS7 data is processed by the SMIME library calls and also by the time stamp (TS) library calls. The TLS implementation in OpenSSL does not call these functions however third party applications would be affected if they call these functions to verify signatures on untrusted data. OpenSSL versions 3.0.0 to 3.0.7 are vulnerable to this issue. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.8. OpenSSL 1.1.1 and 1.0.2 are not affected by this issue. This issue was reported on 13th January 2023 by Hubert Kario and Dmitry Belyavsky (Red Hat). The fix was developed by Tomas Mraz. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20230207.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/general/security-policy.html -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAmPifNgACgkQ1enkP335 7oyMUQ/9FFv+1dJj7l1QP4irYrl6oPkUGK+/KTIxAULv4/OcmknPbIoMzPlN/RnF 5ZQTxIWDLt5PleJapMFvG2hR/DFKD6wmupgQbj1KsU5ExiSLMO41Y1MOyJv2hAcf 338pD2/5loxuO6TNihq3e8k7FDD1dGakAI/RmZii4UFUrNqsmjRH5OObMlV5SE47 Pkf87rI1XuqODYcK+r6IhBD/7yF5WHeTXhKAtbpfxodmyK6Vnr+YrPbxGqQ6d39F 3as6RePfImC5sW6SCeFFxJYaXRlzTs2w3OXMjzA4l0nPSxKLSQjnprGepJ6lI6uV MvJzNnlWPd2Bjq3a/B0fBtBNDgdnojg4je9C+WaKk6dUfsAzsdSFzEY2Aagwh3G5 h1Ud/xzE6y3I6E4BMARHsx0qLTdElDkYApLYAmCcZIVhG9mNohrMw51bAVZ8vyFY XbQylYDDLL7DSv7u5Pcu4IpDkDWMVlvSdo6arJnOtWYjCuRnq5vF6Z0P22Zmwnd2 aUjvgYnsTp1kWtR655QXiHe0fP03S8uo1XntMxKEhJHmvZNjZtb2gD/Rj17bIwhr yOa8Tj1JGFPz6aGW8FvBaL8JaNxRLe5pUyyMlLAokiQD6Aqzc4kIbkC6hp3ZmAAq CJhBTFspEn33shw1fP6vtr6IRDeRB+ku1MvtlDejNEEIZNEHV14= =42lP -----END PGP SIGNATURE----- ----- End forwarded message ----- -- Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b To those we love, we tell the truth; to those we hate, we lie. -unknown Beware https://mindspring.com From nobody Wed Feb 8 14:32:24 2023 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 4PBjFt08VQz3nTdM for ; Wed, 8 Feb 2023 14:35:14 +0000 (UTC) (envelope-from news@mips.inka.de) Received: from mail.inka.de (mail.inka.de [IPv6:2a04:c9c7:0:1073:217:a4ff:fe3b:e77c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PBjFs2lqyz4PVs for ; Wed, 8 Feb 2023 14:35:13 +0000 (UTC) (envelope-from news@mips.inka.de) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of news@mips.inka.de has no SPF policy when checking 2a04:c9c7:0:1073:217:a4ff:fe3b:e77c) smtp.mailfrom=news@mips.inka.de; dmarc=none Received: from mips.inka.de (news@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 1pPlXN-003QC9-A4; Wed, 08 Feb 2023 15:35:05 +0100 Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.16.1/8.16.1) with ESMTP id 318EWORP021700 for ; Wed, 8 Feb 2023 15:32:24 +0100 (CET) (envelope-from news@lorvorc.mips.inka.de) Received: (from news@localhost) by lorvorc.mips.inka.de (8.16.1/8.16.1/Submit) id 318EWOlH021699 for freebsd-security@freebsd.org; Wed, 8 Feb 2023 15:32:24 +0100 (CET) (envelope-from news) To: freebsd-security@freebsd.org From: Christian Weisgerber Newsgroups: list.freebsd.security Subject: Re: [openssl@openssl.org: OpenSSL Security Advisory] Date: Wed, 8 Feb 2023 14:32:24 -0000 (UTC) Message-ID: References: User-Agent: slrn/1.0.3 (FreeBSD) X-Spamd-Result: default: False [-1.67 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.87)[-0.866]; FORGED_SENDER(0.30)[naddy@mips.inka.de,news@mips.inka.de]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[inka.de]; MLMMJ_DEST(0.00)[freebsd-security@freebsd.org]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[news]; ARC_NA(0.00)[]; ASN(0.00)[asn:202113, ipnet:2a04:c9c0::/29, country:DE]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; FROM_NEQ_ENVFROM(0.00)[naddy@mips.inka.de,news@mips.inka.de] X-Rspamd-Queue-Id: 4PBjFs2lqyz4PVs X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org On 2023-02-08, The Doctor wrote: > Any concerns vis-a-vis FreeBSD? Yes, OpenSSL in base needs to be updated to 1.1.1t... *checks git* ... which has already happened in main, stable/13 and stable/12. I assume advisories will be forthcoming. -- Christian "naddy" Weisgerber naddy@mips.inka.de From nobody Wed Feb 8 15:35:03 2023 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 4PBkc15wjRz3nXkt for ; Wed, 8 Feb 2023 15:36:01 +0000 (UTC) (envelope-from doctor@doctor.nl2k.ab.ca) Received: from doctor.nl2k.ab.ca (doctor.nl2k.ab.ca [204.209.81.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PBkc13x8yz3HZj for ; Wed, 8 Feb 2023 15:36:01 +0000 (UTC) (envelope-from doctor@doctor.nl2k.ab.ca) Authentication-Results: mx1.freebsd.org; none Received: from doctor by doctor.nl2k.ab.ca with local (Exim 4.96) (envelope-from ) id 1pPmTP-0009aH-1k; Wed, 08 Feb 2023 08:35:03 -0700 Date: Wed, 8 Feb 2023 08:35:03 -0700 From: The Doctor To: Christian Weisgerber Cc: freebsd-security@freebsd.org Subject: Re: [openssl@openssl.org: OpenSSL Security Advisory] Message-ID: References: List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4PBkc13x8yz3HZj X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6171, ipnet:204.209.81.0/24, country:CA] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Wed, Feb 08, 2023 at 02:32:24PM -0000, Christian Weisgerber wrote: > On 2023-02-08, The Doctor wrote: > > > Any concerns vis-a-vis FreeBSD? > > Yes, OpenSSL in base needs to be updated to 1.1.1t... *checks git* > ... which has already happened in main, stable/13 and stable/12. > > I assume advisories will be forthcoming. > I have been waiting since yesterday! > -- > Christian "naddy" Weisgerber naddy@mips.inka.de > -- Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b To those we love, we tell the truth; to those we hate, we lie. -unknown Beware https://mindspring.com From nobody Wed Feb 8 16:41:12 2023 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 4PBm3W6Lj4z3ndjP for ; Wed, 8 Feb 2023 16:41:27 +0000 (UTC) (envelope-from trond.endrestol@ximalas.info) Received: from enterprise.ximalas.info (enterprise.ximalas.info [IPv6:2001:700:1100:1::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ximalas.info", Issuer "Hostmaster ximalas.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PBm3V4vpQz3PTs for ; Wed, 8 Feb 2023 16:41:26 +0000 (UTC) (envelope-from trond.endrestol@ximalas.info) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ximalas.info header.s=default header.b=Wukf86w3; spf=pass (mx1.freebsd.org: domain of trond.endrestol@ximalas.info designates 2001:700:1100:1::8 as permitted sender) smtp.mailfrom=trond.endrestol@ximalas.info; dmarc=pass (policy=reject) header.from=ximalas.info Received: from enterprise.ximalas.info (Ximalas@localhost [127.0.0.1]) by enterprise.ximalas.info (8.17.1/8.17.1) with ESMTPS id 318GfCHb003349 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 8 Feb 2023 17:41:12 +0100 (CET) (envelope-from trond.endrestol@ximalas.info) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ximalas.info; s=default; t=1675874472; bh=I336z2U9ajE5H3OLfY7xGuOuQ0izDH3t5wmMX4CiAHs=; h=Date:From:To:Subject:In-Reply-To:References; b=Wukf86w3kO9HmQcvMKs94yQYpFHWPYl+CI7w2B9IDWEnuvgCeG4aQs8YO8PRuBC/1 gv6R8hvKRE8PHFI4k6SGQnJjXffTLPAFso8HioBxyZJSfifv0HfVa35IJRkHaVOGz7 vALu0kJ0eLAbJsq8B3L87UJQU4zQ9PuHgvgLAy2IWyH45gLr4IBQMWy96Cs2NCglY0 wl3sWyhl4iOXyjilvzT9YTwNbGneok6i/r2URRVFtrx6p2DnGGilej6529alsKuqvc O9Oxn62j3iu2u6MSeUH+PEzoGxr3tCi7j8MxMau66xpqTy9XzY8nD/tKVlTZEifztE LB54jovjurTzg== Received: from localhost (trond@localhost) by enterprise.ximalas.info (8.17.1/8.17.1/Submit) with ESMTP id 318GfCjb003323 for ; Wed, 8 Feb 2023 17:41:12 +0100 (CET) (envelope-from trond.endrestol@ximalas.info) X-Authentication-Warning: enterprise.ximalas.info: trond owned process doing -bs Date: Wed, 8 Feb 2023 17:41:12 +0100 (CET) From: =?UTF-8?Q?Trond_Endrest=C3=B8l?= To: freebsd-security@freebsd.org Subject: Re: [openssl@openssl.org: OpenSSL Security Advisory] In-Reply-To: Message-ID: <1edf53ab-65d6-dcd9-00be-7d198daa7f40@ximalas.info> References: OpenPGP: url=http://ximalas.info/about/tronds-openpgp-public-key List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3591332809-1933209880-1675874472=:7398" X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF autolearn=unavailable autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on enterprise.ximalas.info X-Spamd-Result: default: False [-2.37 / 15.00]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_MIXED_CHARSET(0.63)[subject]; DMARC_POLICY_ALLOW(-0.50)[ximalas.info,reject]; R_DKIM_ALLOW(-0.20)[ximalas.info:s=default]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; MLMMJ_DEST(0.00)[freebsd-security@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:224, ipnet:2001:700::/32, country:NO]; MIME_TRACE(0.00)[0:+,1:+]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[ximalas.info:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; HAS_XAW(0.00)[]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PBm3V4vpQz3PTs X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3591332809-1933209880-1675874472=:7398 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Wed, 8 Feb 2023 08:35-0700, The Doctor wrote: > On Wed, Feb 08, 2023 at 02:32:24PM -0000, Christian Weisgerber wrote: > > On 2023-02-08, The Doctor wrote: > > > > > Any concerns vis-a-vis FreeBSD? > > > > Yes, OpenSSL in base needs to be updated to 1.1.1t... *checks git* > > ... which has already happened in main, stable/13 and stable/12. > > > > I assume advisories will be forthcoming. > > I have been waiting since yesterday! Hopefully, this can be combined with OpenSSH 9.2p1 due next week. -- ---------------------------------------------------------------------- Trond Endrestøl | Trond.Endrestol@ximalas.info Member of ACM, NAS, NUUG, USENIX | FreeBSD 13.2-P & Alpine 2.26 --3591332809-1933209880-1675874472=:7398-- From nobody Wed Feb 8 19:08:33 2023 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 4PBqKF25cBz3npB6 for ; Wed, 8 Feb 2023 19:08:33 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PBqKF1Y28z467Q; Wed, 8 Feb 2023 19:08:33 +0000 (UTC) (envelope-from security-advisories@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1675883313; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc; bh=Ab5uT2bsGKVQJaKagd651jR+NqTWu3spOOSpNdo3EEA=; b=rG7G0o2vbZMiVYwIwxaUEDvIDLsmHml9IsgC12mlQzDm0R+KRLAAk7Gv4H/tvOBwo9JZqU d+WSwIjunZlDgh37WnBBK/BRMXHmasd1d4d5r3E/myy9jyoXiKOqxqAdBHo429sc7kQyB8 nfVJJRt/6OP2AWB6DCV5fk8WYW9J4XjRgLN6cIPZ6DcWnV10kv642uzjNhdhS9aP9w+2YV jVKzt0RKJ7XdG87dcAmbAqhFUyL4cxtyfcaI5dbyEShRWXD0NGLw/0YpBqLDhrd7jcmG76 g70ABAc6Hh/rjM6aPaqgg87TqKnkxZFDDeiMfxZmsfSLZuDeIl/lNwuZjX4AvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1675883313; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc; bh=Ab5uT2bsGKVQJaKagd651jR+NqTWu3spOOSpNdo3EEA=; b=rmrKMAR6ZVvaPDJ+28LtwcTLrirqjTAKg2h/444OXU79fKdQpWTaWv5ZbS4StDmuV6/PtX 0Felgcv7sGYBYeA6HAOvjVkbLf29tFJdpMgn9/+oQurP1uvrWcm9zQyw8/CSv7OU/YGe98 KTDoGNkRTBr1Kx48WDpFXx4Mx95/kKiV/f44vL27fqGSsscy7VbRzT09iQPZhwPKzpmujs p3yrCpJpdhVlowoQUccsWk3pHe6h83BcZPAPQE0x1Dn51vwysrzirCnJMDgwK09o5o3XOj 6/AQWq/vGEvQ0D9ln2GvvyCUycbM9bNazkZQDi4H/CkyNyjkmXWFLwUiw8DTpg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1675883313; a=rsa-sha256; cv=none; b=TRgDo5QrDa1NikWrnHE57BEDuuhj5OflzckSfsFreNQA3bNhpdeE3XgJWOKuHOzotFWb0+ 0uHSen7GK3fsb5h1N19HK52TkWaHpaggQuMbZbGsVvsAekwQlRd+Ht3hrIfz8ddCiCl/uS /TfrglzxnUKC+P1k0DHQleTjiqAiHGMIt7HCs5psFQr4gI4PuLiMaNkuEBQprpSvgbetvz yRajmChx5JslLtTlTquUineBrqJwyh0sZAjQTP+atyxkIZUdLF/K09579o2WA9komWmJ0B AtGnXxEKtLjqRcDCq46m0OWHSlYJKL8kqEq/9iIeT+T8rUVQceeyJlusp4K6+g== Received: by freefall.freebsd.org (Postfix, from userid 945) id 1DF6F8824; Wed, 8 Feb 2023 19:08:33 +0000 (UTC) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-23:01.geli Reply-To: freebsd-security@freebsd.org Precedence: bulk Message-Id: <20230208190833.1DF6F8824@freefall.freebsd.org> Date: Wed, 8 Feb 2023 19:08:33 +0000 (UTC) X-ThisMailContainsUnwantedMimeParts: N List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-23:01.geli Security Advisory The FreeBSD Project Topic: GELI silently omits the keyfile if read from stdin Category: core Module: geli Announced: 2023-02-08 Credits: Nathan Dorfman Affects: All supported versions of FreeBSD. Corrected: 2023-02-08 18:03:19 UTC (stable/13, 13.1-STABLE) 2023-02-08 18:06:31 UTC (releng/13.1, 13.1-RELEASE-p6) 2023-02-08 18:05:45 UTC (stable/12, 12.4-STABLE) 2023-02-08 18:30:27 UTC (releng/12.4, 12.4-RELEASE-p1) 2023-02-08 18:28:31 UTC (releng/12.3, 12.3-RELEASE-p11) CVE Name: CVE-2023-0751 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background GELI is a block device-layer disk encryption utility. It uses a random master key to perform symmetric cryptography on sectors. The master key is encrypted using a user key, which might consist of up to two components: a user passphrase and a key file. The key file might be read from a file or a standard input. GELI also allows to initialization of multiple devices with a single command. II. Problem Description When GELI reads a key file from a standard input, it doesn't store it anywhere. If the user tries to initialize multiple providers at once, for the second and subsequent devices the standard input stream will be already empty. In this case, GELI silently uses a NULL key as the user key file. If the user used only a key file without a user passphrase, the master key was encrypted with an empty key file. This might not be noticed if the devices were also decrypted in a batch operation. III. Impact Some GELI providers might be silently encrypted with a NULL key file. IV. Workaround On affected systems, instead of initializing GELI devices in a batch operation, the recommended way is to do this operation on a single provider. V. Solution If the system already has the device initialized with a null key, the master key has to be encrypted: echo -n | geli setkey -k- -p -K /path/to/keyfile -P /dev/provider Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date, and reboot. Perform one of the following: 1) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the amd64, i386, or (on FreeBSD 13 and later) arm64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install # shutdown -r +10min "Rebooting for a security update" 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch https://security.FreeBSD.org/patches/SA-23:01/geli.patch # fetch https://security.FreeBSD.org/patches/SA-23:01/geli.patch.asc # gpg --verify geli.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. VI. Correction details This issue is corrected by the corresponding Git commit hash or Subversion revision number in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/13/ 88bb08452ee3 stable/13-n254412 releng/13.1/ 98933c7013a5 releng/13.1-n250179 stable/12/ r372910 releng/12.4/ r372917 releng/12.3/ r372913 - ------------------------------------------------------------------------- For FreeBSD 13 and later: Run the following command to see which files were modified by a particular commit: # git show --stat Or visit the following URL, replacing NNNNNN with the hash: To determine the commit count in a working tree (for comparison against nNNNNNN in the table above), run: # git rev-list --count --first-parent HEAD For FreeBSD 12 and earlier: Run the following command to see which files were modified by a particular revision, replacing NNNNNN with the revision number: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEthUnfoEIffdcgYM7bljekB8AGu8FAmPj8B8ACgkQbljekB8A Gu8Q2g//WfBcATFcQsXQC/fO8oGa90pZl3+mBIBabMO7bMsZ3jzmsZM0DjEuztDM sOY6g9ExN5Fmh4O6Mvg12FjtsbJwp/4KxsrfjG3F8aTKjTKTdbBqhDodwQwCL9ZF u+qkNMrtdqFvigGqmCpKq6vC7kYx12NVFvr4X81kgBmwCOPUKlD351lnkQKv0C5B G3HeLdQb7stMRcnHWcqOw7m98aRSU0gE2/9BAMqfvtVWboa6LrdF6PQVav8Lq417 qh8Md71IAAWyFm8jcOtsX949KdtI1kcwDbVyuO5mT6TNFTuEu/lIx78/YpvGVZUt 1a7FAkiekr6c19xC01o6muc6E1XiwxO/vQMMwEsW9lv+N2fm4d7EGUP3nvFZTzgt OOKVORcqEsdZj92/UDdUXsIFV7fja0t7rGUXhI/YTAtnOvESTvDkUzfNQ3fxIMcG COFQdxJ0+P2oItMSeY2dlN8A/z41N6BqAilmg/LxuzZkCblC8q0JxLoAsAEydT4j RHA7dTwFNeM+6kVluERX302l6JGogg6mB+o/O+vqKWfDrvEzv7CLHEGnBT6lcAkX x1RQwXFd84fHwWXAffsUNKxrQe0QI+dbPcGH0YtHZntno1Azds3oVBAFa5nUcYVD 3A8ShP18hwkVLRyG9680fSD5cQwYKZpLuasujikLqnme/PkYDy4= =6d7v -----END PGP SIGNATURE----- From nobody Wed Feb 8 19:41:55 2023 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 4PBr3q6SK5z3p7xf for ; Wed, 8 Feb 2023 19:41:59 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PBr3q41N2z3D7f for ; Wed, 8 Feb 2023 19:41:59 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-qt1-x82e.google.com with SMTP id g8so22151205qtq.13 for ; Wed, 08 Feb 2023 11:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Q58wnw5yUCXgDcD3jFF5exFtcODXx4525L9NIRJOrxA=; b=j6ntSnxws5vzInpharWjKx704BdsKJg66IUrAw+1sQZTzZSCxPoBBlmJjcjHWK+EoY HGD+zoTLR+VU3dJ9YqOk7HwgWp6HmsafN4nUzVDzJwbMllkvpbiy5ywGoT7w/xUkjVdA 0S/ogqF+mhsN3vWc6YqUA/WPnHC1qwf+SZDx6DaMJNBRnI1Fr2v+tsxMbuoGndlPr0dg PWpeVbah7gJVI5SkcdMJeN23YMWWOEhlU+jabsj6vHzQnqy1E47awNo0+GFnVYNCq6jF JRGSQqdFEMFLVAP6bXzr34C5dJ+1Ta180iAdqy89V19PX1diE+bfa0ABk4hYBHv3q/1f k7pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Q58wnw5yUCXgDcD3jFF5exFtcODXx4525L9NIRJOrxA=; b=SUOHXfFrLuCIeUTfK6iXARG29ZbbnsPVfHbjfcHtL+oujuyZVTHj3MOIhAMJYHN5mh 8ku+r4ryTA8fuKeI//2ECui5UDRlfyzOca3F1dNzvARa1MVw29Gtp0vBMn42pB1P6d1l qr0jnyekGwySwl94SuCPC1Hu8x2LgyIi3tCo2XCIA98ow+Cm+2yxIXxxonMGhe/cyc7K 2tOU/i0ZTnyrnvHq7CyZqN1fn8cAL3ep6gNZvwRWGWljEhNqW3wdbRotmseHMHdhZzbM ziM9399TLqACRBJw0MYeiNExatxL2pei5etu4NM2GlExGLcQ1NCUmlpB+s0Ubii6puZ7 eLHQ== X-Gm-Message-State: AO0yUKVDJjOl/YHUBxpvitWtpfPU5ahQvYDu/pXn23SoNirBlKWsfAIg hXQpMie9wi0/xVrBmyKZPb3BVf+UGNvGLAcfnfmFUaz0ZIRFc0gR5yd2yzK+acZDvoakng0pYtD Z3qG+uZZ+fdz70ObWkB4r9964J15eVWu6Rw/lJjSQky7UMdg6MSfFEP9s6XR++qbxmyINnkmds0 kjL7/VdNJEy5YJNg== X-Google-Smtp-Source: AK7set9p3jJeTEPhbOKAqgbl0QwXTb7xxHa1jz+KFKOuRj3vYoueepokVQo29v753SXF95HwGR1aPA== X-Received: by 2002:ac8:5ac3:0:b0:3b7:ec87:8154 with SMTP id d3-20020ac85ac3000000b003b7ec878154mr10226179qtd.44.1675885317537; Wed, 08 Feb 2023 11:41:57 -0800 (PST) Received: from mutt-hbsd (pool-100-16-219-215.bltmmd.fios.verizon.net. [100.16.219.215]) by smtp.gmail.com with ESMTPSA id f3-20020ac84703000000b003b2d890752dsm11941852qtp.88.2023.02.08.11.41.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Feb 2023 11:41:55 -0800 (PST) Date: Wed, 8 Feb 2023 14:41:55 -0500 From: Shawn Webb To: freebsd-security@freebsd.org Cc: FreeBSD Security Advisories Subject: Re: FreeBSD Security Advisory FreeBSD-SA-23:01.geli Message-ID: <20230208194155.hs5fkfdqcfmd72ld@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <20230208190833.1DF6F8824@freefall.freebsd.org> List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rjrbp2jw6phlm663" Content-Disposition: inline In-Reply-To: <20230208190833.1DF6F8824@freefall.freebsd.org> X-Rspamd-Queue-Id: 4PBr3q41N2z3D7f X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --rjrbp2jw6phlm663 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 08, 2023 at 07:08:33PM +0000, FreeBSD Security Advisories wrote: > -----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-23:01.geli Security Advi= sory > The FreeBSD Pro= ject >=20 > Topic: GELI silently omits the keyfile if read from stdin >=20 > Category: core > Module: geli > Announced: 2023-02-08 > Credits: Nathan Dorfman > Affects: All supported versions of FreeBSD. > Corrected: 2023-02-08 18:03:19 UTC (stable/13, 13.1-STABLE) > 2023-02-08 18:06:31 UTC (releng/13.1, 13.1-RELEASE-p6) > 2023-02-08 18:05:45 UTC (stable/12, 12.4-STABLE) > 2023-02-08 18:30:27 UTC (releng/12.4, 12.4-RELEASE-p1) > 2023-02-08 18:28:31 UTC (releng/12.3, 12.3-RELEASE-p11) > CVE Name: CVE-2023-0751 >=20 > For general information regarding FreeBSD Security Advisories, > including descriptions of the fields above, security branches, and the > following sections, please visit . >=20 > I. Background >=20 > GELI is a block device-layer disk encryption utility. It uses a random > master key to perform symmetric cryptography on sectors. The master key = is > encrypted using a user key, which might consist of up to two components: a > user passphrase and a key file. The key file might be read from a file o= r a > standard input. GELI also allows to initialization of multiple devices w= ith > a single command. >=20 > II. Problem Description >=20 > When GELI reads a key file from a standard input, it doesn't store it > anywhere. If the user tries to initialize multiple providers at once, for > the second and subsequent devices the standard input stream will be alrea= dy > empty. In this case, GELI silently uses a NULL key as the user key file.= If > the user used only a key file without a user passphrase, the master key w= as > encrypted with an empty key file. This might not be noticed if the devic= es > were also decrypted in a batch operation. >=20 > III. Impact >=20 > Some GELI providers might be silently encrypted with a NULL key file. bsdinstall has a nifty option for using geli to encrypt your ZFS root pool (usually named zroot). Are ZFS pools created by bsdinstall impacted? Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --rjrbp2jw6phlm663 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmPj+vsACgkQ/y5nonf4 4frk2g//XKzGZgLGHrugjQHht1YBouo2/cOXJ+TXgJzoUR1ZltaFjCeZQREofwmd ZlCLLneTMicG3kZsUqds4sSKgTNWDdYxNX2XyRqbbSjWasqb1B5wWTwN48xb5uVH mBaSOUkjogVvnkVtsNmO2zz5AUAyPpEDzzHqYQoVsvTn9qkDijBBTaWTlZNFZBLV O8urhNf7S3/IQf4wPHZfoQ5ljL8mZ1nojzPyL0v97M4cWdlw3hMh83mbHDcPqn8r 4NVQFLY0myq+Ktwn0NRRlAFcs3ZwE7rFsSod9Yl6xeneRK0vFPEy+DgwDFqNF/4m koyOaxdLqWvTkF9CCC3Y/zYvaQS46TeODm7TD5HuKvboQz90Tz0lxxI/a1A5SPGQ oKIYbH573rY5fN5KfmWdNhsObqWsFHnOZOG7Y35Z3fJoyL4rQpCehfJ15+CoJuVS 5hzZ6cCH1nUYNyAVT4cTMB9p4GD7Ykb2QaLOf9Ji7v6w6S38s2mqHmlI8BzlUc6h ATZb7vOPwLpLWjwDPgTgnq3qbL4kTqUKLBn0ANyqxd4UwYQHVGtbboOGuWVw5dUU F9rJTQ71nBJkzwtcdv2+OWZuCKtQTBY9SxQjZPy2hBTOL53Xn6QO1506vpMDBc80 CUtwql7s32f0369AaBMy5rrsCFXZHzf1KWt8y1WekUB594KDH2w= =lY+7 -----END PGP SIGNATURE----- --rjrbp2jw6phlm663-- From nobody Wed Feb 8 19:52:52 2023 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 4PBrHX5Z1zz3p8rr for ; Wed, 8 Feb 2023 19:52:08 +0000 (UTC) (envelope-from oshogbo.vx@gmail.com) Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PBrHX3Tl6z3Gkx; Wed, 8 Feb 2023 19:52:08 +0000 (UTC) (envelope-from oshogbo.vx@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-f49.google.com with SMTP id m16-20020a05600c3b1000b003dc4050c94aso2361635wms.4; Wed, 08 Feb 2023 11:52:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xh9RDVX0DMWXg5Un+k8xEu0zPwVS6ASyuKT1x1wTvSw=; b=0Rzr6OnURojKi4Xv6M7+qa5mYB12TqkRyOdNNMbeiCkEB1JXve9N7TJdykNedvvq46 5ZktAg88at4VSlaQHnnky5rA921GAG8q+Fpis3+fejmgGTIEDdkXrI4vVfYQR+aCxB5a 49/FFzFhUTUa228LOQJiqyUuY043sk3BpMFfc9u1ERHNGZNSmwhez4tserPhloGbC0GV 4T/1ivlbxHVu0qbktuNoSOVlR5Uo+Uthb6cwvSQe4cCGNjm601C5owThq9JinyUks9Tu kEcu0DF0yvvhIUmYoefxFPdj4NJeTBtvy9dIrSxI1AYxte2YwWjUMr2gzgcs/U9XJ/OL Im2Q== X-Gm-Message-State: AO0yUKUr9qKAEY+kgMbvHhrBQ5mh8Hkp0JD/fmGsdGRNgwe153VFGqqn igjBoXSR25RDH1BsJjPZlewf9j6xStmRMF2+c/qZLLmzcvpTzw== X-Google-Smtp-Source: AK7set9prVloOdlS1Lrq4HJ2MsybjwEiJg/D88GDlaNpJba/cG40BqvBXVqcErGDt5++3+Y9GArTDzVO590U6ZuQP3A= X-Received: by 2002:a05:600c:3147:b0:3df:fc66:25a with SMTP id h7-20020a05600c314700b003dffc66025amr331789wmo.3.1675885926408; Wed, 08 Feb 2023 11:52:06 -0800 (PST) List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org MIME-Version: 1.0 References: <20230208190833.1DF6F8824@freefall.freebsd.org> <20230208194155.hs5fkfdqcfmd72ld@mutt-hbsd> In-Reply-To: <20230208194155.hs5fkfdqcfmd72ld@mutt-hbsd> From: Mariusz Zaborski Date: Wed, 8 Feb 2023 20:52:52 +0100 Message-ID: Subject: Re: FreeBSD Security Advisory FreeBSD-SA-23:01.geli To: Shawn Webb Cc: freebsd-security@freebsd.org, FreeBSD Security Advisories Content-Type: multipart/alternative; boundary="00000000000053e43805f435996e" X-Rspamd-Queue-Id: 4PBrHX3Tl6z3Gkx X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000053e43805f435996e Content-Type: text/plain; charset="UTF-8" No, each disk is encrypted/initialized separately: https://cgit.freebsd.org/src/tree/usr.sbin/bsdinstall/scripts/zfsboot#n1275 On Wed, 8 Feb 2023 at 20:42, Shawn Webb wrote: > On Wed, Feb 08, 2023 at 07:08:33PM +0000, FreeBSD Security Advisories > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > > ============================================================================= > > FreeBSD-SA-23:01.geli Security > Advisory > > The FreeBSD > Project > > > > Topic: GELI silently omits the keyfile if read from stdin > > > > Category: core > > Module: geli > > Announced: 2023-02-08 > > Credits: Nathan Dorfman > > Affects: All supported versions of FreeBSD. > > Corrected: 2023-02-08 18:03:19 UTC (stable/13, 13.1-STABLE) > > 2023-02-08 18:06:31 UTC (releng/13.1, 13.1-RELEASE-p6) > > 2023-02-08 18:05:45 UTC (stable/12, 12.4-STABLE) > > 2023-02-08 18:30:27 UTC (releng/12.4, 12.4-RELEASE-p1) > > 2023-02-08 18:28:31 UTC (releng/12.3, 12.3-RELEASE-p11) > > CVE Name: CVE-2023-0751 > > > > For general information regarding FreeBSD Security Advisories, > > including descriptions of the fields above, security branches, and the > > following sections, please visit . > > > > I. Background > > > > GELI is a block device-layer disk encryption utility. It uses a random > > master key to perform symmetric cryptography on sectors. The master key > is > > encrypted using a user key, which might consist of up to two components: > a > > user passphrase and a key file. The key file might be read from a file > or a > > standard input. GELI also allows to initialization of multiple devices > with > > a single command. > > > > II. Problem Description > > > > When GELI reads a key file from a standard input, it doesn't store it > > anywhere. If the user tries to initialize multiple providers at once, > for > > the second and subsequent devices the standard input stream will be > already > > empty. In this case, GELI silently uses a NULL key as the user key > file. If > > the user used only a key file without a user passphrase, the master key > was > > encrypted with an empty key file. This might not be noticed if the > devices > > were also decrypted in a batch operation. > > > > III. Impact > > > > Some GELI providers might be silently encrypted with a NULL key file. > > bsdinstall has a nifty option for using geli to encrypt your ZFS root > pool (usually named zroot). Are ZFS pools created by bsdinstall > impacted? > > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > --00000000000053e43805f435996e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, 8 Feb 2023 at 20:42, Shawn Webb <<= a href=3D"mailto:shawn.webb@hardenedbsd.org">shawn.webb@hardenedbsd.org= > wrote:
On W= ed, Feb 08, 2023 at 07:08:33PM +0000, FreeBSD Security Advisories wrote: > -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> =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-23:01.geli=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Security Advisory
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The FreeB= SD Project
>
> Topic:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 GELI silently omits the keyfi= le if read from stdin
>
> Category:=C2=A0 =C2=A0 =C2=A0 =C2=A0core
> Module:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0geli
> Announced:=C2=A0 =C2=A0 =C2=A0 2023-02-08
> Credits:=C2=A0 =C2=A0 =C2=A0 =C2=A0 Nathan Dorfman <ndorf@rtfm.net>
> Affects:=C2=A0 =C2=A0 =C2=A0 =C2=A0 All supported versions of FreeBSD.=
> Corrected:=C2=A0 =C2=A0 =C2=A0 2023-02-08 18:03:19 UTC (stable/13, 13.= 1-STABLE)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02023-02-0= 8 18:06:31 UTC (releng/13.1, 13.1-RELEASE-p6)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02023-02-0= 8 18:05:45 UTC (stable/12, 12.4-STABLE)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02023-02-0= 8 18:30:27 UTC (releng/12.4, 12.4-RELEASE-p1)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02023-02-0= 8 18:28:31 UTC (releng/12.3, 12.3-RELEASE-p11)
> CVE Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0CVE-2023-0751
>
> For general information regarding FreeBSD Security Advisories,
> including descriptions of the fields above, security branches, and the=
> following sections, please visit <URL:https://security.FreeBSD.= org/>.
>
> I.=C2=A0 =C2=A0Background
>
> GELI is a block device-layer disk encryption utility.=C2=A0 It uses a = random
> master key to perform symmetric cryptography on sectors.=C2=A0 The mas= ter key is
> encrypted using a user key, which might consist of up to two component= s: a
> user passphrase and a key file.=C2=A0 The key file might be read from = a file or a
> standard input.=C2=A0 GELI also allows to initialization of multiple d= evices with
> a single command.
>
> II.=C2=A0 Problem Description
>
> When GELI reads a key file from a standard input, it doesn't store= it
> anywhere.=C2=A0 If the user tries to initialize multiple providers at = once, for
> the second and subsequent devices the standard input stream will be al= ready
> empty.=C2=A0 In this case, GELI silently uses a NULL key as the user k= ey file.=C2=A0 If
> the user used only a key file without a user passphrase, the master ke= y was
> encrypted with an empty key file.=C2=A0 This might not be noticed if t= he devices
> were also decrypted in a batch operation.
>
> III. Impact
>
> Some GELI providers might be silently encrypted with a NULL key file.<= br>
bsdinstall has a nifty option for using geli to encrypt your ZFS root
pool (usually named zroot). Are ZFS pools created by bsdinstall
impacted?

Thanks,

--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/m= aster/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
--00000000000053e43805f435996e-- From nobody Wed Feb 8 21:12:42 2023 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 4PBt4Y10L4z3pL0h for ; Wed, 8 Feb 2023 21:12:45 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PBt4X5r7lz3n7B for ; Wed, 8 Feb 2023 21:12:44 +0000 (UTC) (envelope-from grarpamp@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vs1-xe2a.google.com with SMTP id p10so3491vsu.5 for ; Wed, 08 Feb 2023 13:12:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=szcCqKLxiVxUXx7LiejQdFNHlyF+mn+w3eKWm2Qw1+4=; b=Q93zhAzuC9CUvnFvejCbUROURA+0s6eXjVRZHXtN9JRV3tHwfMLtLOEyCA8EFKQn1S UW5B888/0Xq3ClYkJ/8v3N3FmoiUhWSWlP7VUCq4H7PCexO/zKU6LR7ehjkc6V5BihQo 5KRgaSQhXF2daU+pI6RfCd87MrPQIPu9vAG3kf8dN7L/KXuup5n9A21vofiOxQbY9LSt H6YGXXbvI72VpLe3BWzjtP6vx+SC+TO0Ko2yuwy2rT8RP0ck0Li1A+3uR3ekiueFBUSq QyYAerk03Cy96aJD+/6FPu7i02s6Lu8ApRZYRlqvkX7QDqb5QgAwDCo3tW5XAiL8wBr6 77mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=szcCqKLxiVxUXx7LiejQdFNHlyF+mn+w3eKWm2Qw1+4=; b=PDBCraYMc2F95u+2ZbKL2TXFnBx3DoulXOHHIBobaQYntAaSAMFgDVA6OurSwf7DKt bdvhrNgHJ5Hq07T3ExhR9oteY+/EHxtaWhQDTXRrggzqSbH/oo6dnmhOqEXXB5AksxSN 1ft7cBOEeDRhSm+ZsSBmCmLwo6fAdr/RbNgBhqVjGTD7jLkgC4W0kFEYls3lrY56qvKV 0M42zIusdWydJxvekrD6PqzhV49CREoHIGM0Zb5jR8jQSROFS97wK2Mv78UWGvnqAjBU NaxaEvgZpWuDrRWiqKmrR1M9QDIeLqXUnbaDikzEcg5c1HV159uwsqNklmLqxXF5mChn OzYw== X-Gm-Message-State: AO0yUKWr08uHsue5y+Hu5xXE/IO6gq7mHqU+xLPY9OTJizwPZ63HKPpD 51YwRAgiGMF5LJmgXfD4CLdCbNOeM2ew5t2ujO/WLQB5qo29EXrt X-Google-Smtp-Source: AK7set/sXSLJ0MwMi6n/8pZKWOnPuBcmAgHw5KI9N7tSkHVDxp61qhLA6LwKh6GERjBTuu2oA0zmpg8H8BAkrAXoEHA= X-Received: by 2002:a05:6102:441f:b0:411:a14d:6bac with SMTP id df31-20020a056102441f00b00411a14d6bacmr1737313vsb.44.1675890762813; Wed, 08 Feb 2023 13:12:42 -0800 (PST) List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org MIME-Version: 1.0 Received: by 2002:a59:c32b:0:b0:399:45ad:34c4 with HTTP; Wed, 8 Feb 2023 13:12:42 -0800 (PST) In-Reply-To: <20230208190833.1DF6F8824@freefall.freebsd.org> References: <20230208190833.1DF6F8824@freefall.freebsd.org> From: grarpamp Date: Wed, 8 Feb 2023 16:12:42 -0500 Message-ID: Subject: Re: FreeBSD Security Advisory FreeBSD-SA-23:01.geli To: freebsd-security@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4PBt4X5r7lz3n7B X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Did anyone check if -j/-J might have similar edge cases? From nobody Wed Feb 8 22:15:21 2023 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 4PBvRx4BRBz3n012 for ; Wed, 8 Feb 2023 22:14:37 +0000 (UTC) (envelope-from oshogbo.vx@gmail.com) Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PBvRx1BbHz3tWP for ; Wed, 8 Feb 2023 22:14:37 +0000 (UTC) (envelope-from oshogbo.vx@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-f47.google.com with SMTP id f47-20020a05600c492f00b003dc584a7b7eso2597771wmp.3 for ; Wed, 08 Feb 2023 14:14:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IUkjzRtUEEOVnzXqgurHmWwr/2JWUDXVPUHKFhhyjSc=; b=i9aUA+ANAcsReTag3UdpkAGZZQ64JTy7gm5Mx0Xmi7BX6oSoI+4irNFik44JRTGl1d UxzEx5zYX/zUzPh017zxodzTaI9DCn8Vzjbsa+1tY8Oa9uqC53iBtGBYLxfcWyuOAqPE nY0gk2YLxMVAoeyVIUawI3us2cqmtZOQd2s+Ihz47hRIYCOz30Njc2mxn2ZDubo3ZGE9 8HxeHV+fK15KOrt+e7mHeFDHMgQUAjqWorndYwAn7CvybhWw6mWvKl4Af29POqRyAl3E WZS2BUZGbZJoiYkchce3D5CueqC1fQZ65bDkph43OKfDngAYGiyqwB45xkwsc1k5JsWV q+Eg== X-Gm-Message-State: AO0yUKU2sUrHMU8Jmp0NDFGEDf1uOa/Rd5at/VtYv0QUcZnHP/fF6sfw YHrcZ9I3/tdA8PKcyi2HCVUomJtnDzsLEYVmF+3vpQhfjJVMVQ== X-Google-Smtp-Source: AK7set89DdOWkrKy7S59W/ngGftqEfBHjjIwCFUPjdxRo9ekZPMZIMz1xIFY77h1SWdhMsqyJIa7eahLlE3yu9gbgp8= X-Received: by 2002:a05:600c:3147:b0:3df:fc66:25a with SMTP id h7-20020a05600c314700b003dffc66025amr359316wmo.3.1675894475569; Wed, 08 Feb 2023 14:14:35 -0800 (PST) List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org MIME-Version: 1.0 References: <20230208190833.1DF6F8824@freefall.freebsd.org> In-Reply-To: From: Mariusz Zaborski Date: Wed, 8 Feb 2023 23:15:21 +0100 Message-ID: Subject: Re: FreeBSD Security Advisory FreeBSD-SA-23:01.geli To: grarpamp Cc: freebsd-security@freebsd.org Content-Type: multipart/alternative; boundary="000000000000e5c09b05f43796f2" X-Rspamd-Queue-Id: 4PBvRx1BbHz3tWP X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000e5c09b05f43796f2 Content-Type: text/plain; charset="UTF-8" When I was working on the patch, I analyzed this situation. The issue with key files is that they can be arbitrary in size, and I think this caused this issue. The passfile/passwords are limited in size. Because they are limited, they are cached in the memory of geli and reused. My conclusion was that there isn't such an issue with them. Ofc it is always good to double-check. You can follow the usage of the cached_passphrase variable: https://cgit.freebsd.org/src/tree/lib/geom/eli/geom_eli.c#n71 On Wed, 8 Feb 2023 at 22:13, grarpamp wrote: > Did anyone check if -j/-J might have similar edge cases? > > --000000000000e5c09b05f43796f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
When I was working on the patch, I analyz= ed this situation.
The issue with key files is that they can be arbitrar= y in size, and I think this caused this issue.
The pa= ssfile/passwords are limited in size.
Because they are limited, they ar= e cached in the memory of geli and reused.

My conc= lusion was that there isn't such an issue with them.
Ofc it is always good to double-check. You can follow the usage of = the cached_passphrase variable:
https://cgit.freebsd.org/src/tree/lib/geo= m/eli/geom_eli.c#n71

On Wed, 8 Feb 2023 at 22:13, grarpamp <grarpamp@gmail.com> wrote:
Did anyone check if -j/-J migh= t have similar edge cases?

--000000000000e5c09b05f43796f2-- From nobody Wed Feb 8 22:39:55 2023 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 4PBw1G4fwHz3n2w0 for ; Wed, 8 Feb 2023 22:40:02 +0000 (UTC) (envelope-from doctor@doctor.nl2k.ab.ca) Received: from doctor.nl2k.ab.ca (doctor.nl2k.ab.ca [204.209.81.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PBw1G2Kf1z3xd2 for ; Wed, 8 Feb 2023 22:40:02 +0000 (UTC) (envelope-from doctor@doctor.nl2k.ab.ca) Authentication-Results: mx1.freebsd.org; none Received: from doctor by doctor.nl2k.ab.ca with local (Exim 4.96) (envelope-from ) id 1pPt6Z-0009mK-1O; Wed, 08 Feb 2023 15:39:55 -0700 Date: Wed, 8 Feb 2023 15:39:55 -0700 From: The Doctor To: Trond Endrest??l Cc: freebsd-security@freebsd.org Subject: Re: [openssl@openssl.org: OpenSSL Security Advisory] Message-ID: References: <1edf53ab-65d6-dcd9-00be-7d198daa7f40@ximalas.info> List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1edf53ab-65d6-dcd9-00be-7d198daa7f40@ximalas.info> X-Rspamd-Queue-Id: 4PBw1G2Kf1z3xd2 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6171, ipnet:204.209.81.0/24, country:CA] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Wed, Feb 08, 2023 at 05:41:12PM +0100, Trond Endrest??l wrote: > On Wed, 8 Feb 2023 08:35-0700, The Doctor wrote: > > > On Wed, Feb 08, 2023 at 02:32:24PM -0000, Christian Weisgerber wrote: > > > On 2023-02-08, The Doctor wrote: > > > > > > > Any concerns vis-a-vis FreeBSD? > > > > > > Yes, OpenSSL in base needs to be updated to 1.1.1t... *checks git* > > > ... which has already happened in main, stable/13 and stable/12. > > > > > > I assume advisories will be forthcoming. > > > > I have been waiting since yesterday! > > Hopefully, this can be combined with OpenSSH 9.2p1 due next week. > Openssh 9.2 has been out for 2 weeks. > -- > ---------------------------------------------------------------------- > Trond Endrest??l | Trond.Endrestol@ximalas.info > Member of ACM, NAS, NUUG, USENIX | FreeBSD 13.2-P & Alpine 2.26 -- Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b Sometimes what's billed as light is the darkness. -unknown Beware https://mindspring.com From nobody Thu Feb 9 22:23:05 2023 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 4PCWbj3ykYz3p89C for ; Thu, 9 Feb 2023 22:23:29 +0000 (UTC) (envelope-from woodsb02@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PCWbj3S22z4PhZ; Thu, 9 Feb 2023 22:23:29 +0000 (UTC) (envelope-from woodsb02@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1675981409; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BrZv8DvvhE43IvmCLk26oqr195mhuesY9HxkdxB0dT8=; b=n89l2GPjflFHpNiApUHmyxH/s5noRnX+O1M8XQpow9tHWgGqcO7BEvdpW0YvQNNAlTeznR yeTjRmcwQFVa9weZO3Y/MXnmizwiiqndNIqpdbl61/DXYlaayMjWWIe9rYg7Pztkb0KqLE P97I/trV1sErfxVTxuR7wJJztN8SfVoJ/4kSIyxk7RNQMuBQtselGZBCNtnaIO8V/HXJYq uDtVuXX2CZgKsMKNX8ky071A5wu7aWNALZXX5L7Vwn3nSvH1Qr6dufyA08kTTm1IVqeSSD Rr+RDljDZGTTIPLqYCRiqhCCoc3tyfqvhm1im/rH+Vu12ioOckj/URNwBHZVPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1675981409; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BrZv8DvvhE43IvmCLk26oqr195mhuesY9HxkdxB0dT8=; b=odIB8DopYJVpD0Hs/rSdEz/ZykEEG+q2SbKKx//pDR9KZa34rjKLUJWpiL/CS7ssk+rs+6 TbB0JPGw16BIrqDpevJi7PjyNWEyWiCix0l3sGdY0FrFBaqNdyhIBjpKnk9HC9lpERXPmX fkNhgcI3yt0VS1gAZcOLXDn65dpYa7L+kyfJbMkPv+tXuCPnkS9rUzwaly3JtMwk/zkurh QW4KD8wcPZtEeb0VcuBwsYFH3kHvm4OY+GV7/zdJecs3K8bjoS/dPSBPBs5Fes70HaO1g7 0DQ6CmzFU2mTmxlk1bv8LHcrkDw0Fc7a2gSbj+D8MxWhSUGEsSmlSDS/0U4hEw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1675981409; a=rsa-sha256; cv=none; b=cuRu6if4MPu2vcpmJxKjLq7Iu8lWH2YTUNzcAXzwiLgPp5EAQhmfcXbxeCYMAmJpXWvHHa 5JhGa7KHOD4FRyHelcIV3dH5NAabyb5s7rU7HmjRi+Y8tIv9/eJKTWzTHDo2TzJ4zg3/jB Db5ynUdXOVzDeA4aJRKVzHfZcJe5GwdVylyWucGSivlv65suoa7CIysxhWGLtSplseiFlp 6olFEW5Ou1VH65n6EdwhoGYEPCWKrGmXhSuGc/Pi/Fss3NUCneA4eIWQBOXMD1jp3n5HWB Hc3CxArqNPUdMLSCIAXYIj5KUVLihBGQhEVqzxV2Sx0R1RRsbBzXVBUzo1g5kQ== Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: woodsb02) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PCWbj2BrqzXwP; Thu, 9 Feb 2023 22:23:29 +0000 (UTC) (envelope-from woodsb02@freebsd.org) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailauth.nyi.internal (Postfix) with ESMTP id B916C27C0054; Thu, 9 Feb 2023 17:23:27 -0500 (EST) Received: from imap46 ([10.202.2.96]) by compute1.internal (MEProxy); Thu, 09 Feb 2023 17:23:27 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudehfedgudehkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvvefutgfgsehtqhertderreejnecuhfhrohhmpedf uegvnhcuhghoohgushdfuceofihoohgushgstddvsehfrhgvvggsshgurdhorhhgqeenuc ggtffrrghtthgvrhhnpeelfedtudeigefgiedvgfehffdtgfeiieduvdeiheevjeffhffg ueegieetgfehfeenucffohhmrghinhepfhhrvggvsghsugdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsvghnodhmvghsmhhtphgr uhhthhhpvghrshhonhgrlhhithihqddutdelfeeiiedvkeekqddvgeejkedvvdektddqfi hoohgushgstddvpeepfhhrvggvsghsugdrohhrghesfihoohgushdrrghm X-ME-Proxy: Feedback-ID: if9c9472a:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6B1402A20085; Thu, 9 Feb 2023 17:23:27 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-156-g081acc5ed5-fm-20230206.001-g081acc5e List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org Mime-Version: 1.0 Message-Id: In-Reply-To: <20230208190833.283D087C3@freefall.freebsd.org> References: <20230208190833.283D087C3@freefall.freebsd.org> Date: Fri, 10 Feb 2023 06:23:05 +0800 From: "Ben Woods" To: freebsd-security@freebsd.org Cc: "Nathan Dorfman" , "Mariusz Zaborski" , "Gordon Tetlow" , "Philip Paeps" , "Alan Somers" , "Maksym Sobolyev" Subject: Re: FreeBSD Security Advisory FreeBSD-SA-23:01.geli Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ThisMailContainsUnwantedMimeParts: N On Thu, 9 Feb 2023, at 3:08 AM, FreeBSD Security Advisories wrote: > FreeBSD-SA-23:01.geli Security A= dvisory > The FreeBSD = Project > > Topic: GELI silently omits the keyfile if read from stdin Good morning, I was scrolling through my emails yesterday and spat my coffee out when = I read this one. I just wanted to put my hand up and say I believe this = issue originates from my code, when I added the =E2=80=9Cgeli init multi= ple providers=E2=80=9D feature in 2018 just prior to the FreeBSD-12 rele= ase. https://reviews.freebsd.org/D16115 https://reviews.freebsd.org/D17096 Apologies to anyone affected, and thank you to Nathan for reporting it, = Marius, Gordon and Philip for fixing it, and anyone else on the security= team for investigating/communicating the issue. I=E2=80=99ll spend some time to review the fix to fully understand where= I went wrong. I was also wondering why it wasn=E2=80=99t revealed by my= testing at the time=E2=80=A6. And then I realised this would not be vis= ible to the user as they would still enter their user key to successfull= y add the device with a null master key. Slaps forehead. I never got around to adding unit tests for init/attach multiple provide= rs as was requested by Alan Somers at the time (sorry), but I suspect ev= en if I had they would have passed because I wouldn=E2=80=99t have thoug= ht to test for this scenario. Regards, Ben --=20 From: Ben Woods woodsb02@freebsd.org From nobody Fri Feb 10 01:48:23 2023 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 4PCc8L2WC8z3prHN for ; Fri, 10 Feb 2023 01:48:34 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from echo.brtsvcs.net (echo.brtsvcs.net [208.111.40.118]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PCc8K1BQYz3vb2; Fri, 10 Feb 2023 01:48:33 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of list_freebsd@bluerosetech.com designates 208.111.40.118 as permitted sender) smtp.mailfrom=list_freebsd@bluerosetech.com; dmarc=none Received: from chombo.houseloki.net (65-100-43-2.dia.static.qwest.net [65.100.43.2]) by echo.brtsvcs.net (Postfix) with ESMTPS id B0D8238D00; Fri, 10 Feb 2023 01:48:25 +0000 (UTC) Received: from [10.26.25.100] (ivy.pas.ds.pilgrimaccounting.com [10.26.25.100]) by chombo.houseloki.net (Postfix) with ESMTPSA id 4D2A812863; Thu, 9 Feb 2023 17:48:25 -0800 (PST) Subject: Re: FreeBSD Security Advisory FreeBSD-SA-23:01.geli To: freebsd-security@freebsd.org, FreeBSD Security Advisories References: <20230208190833.1DF6F8824@freefall.freebsd.org> From: Mel Pilgrim Message-ID: Date: Thu, 9 Feb 2023 17:48:23 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org MIME-Version: 1.0 In-Reply-To: <20230208190833.1DF6F8824@freefall.freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-security@freebsd.org]; ASN(0.00)[asn:36236, ipnet:208.111.40.0/24, country:US]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[bluerosetech.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PCc8K1BQYz3vb2 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On 2023-02-08 11:08, FreeBSD Security Advisories wrote: > ============================================================================= > FreeBSD-SA-23:01.geli Security Advisory > The FreeBSD Project > > Topic: GELI silently omits the keyfile if read from stdin How do I test my existing devices to see if the master key needs to be encrypted? Does the solution change if the keyfiles don't require passwords? I use GELI keyfiles without passwords for unattended reboots. From nobody Fri Feb 10 11:25:03 2023 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 4PCrxm40q1z3pptW for ; Fri, 10 Feb 2023 11:25:16 +0000 (UTC) (envelope-from oshogbo.vx@gmail.com) Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PCrxm2LJWz3spg; Fri, 10 Feb 2023 11:25:16 +0000 (UTC) (envelope-from oshogbo.vx@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wr1-f41.google.com with SMTP id bu23so4733164wrb.8; Fri, 10 Feb 2023 03:25:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qYS1/JW5r17Dz8YkfgsaocjpyWo7Vwfm0oY56DroBZ8=; b=dWvmWw8BrXevONlSxXY+u+BU1ekyM8JOn5tiIIGhS06mCr7B9v/pY308t2/acH9+Sx 4bwcPjw/lHxZJ7kcLGD0in0+zK1ivpai95VDkiEsn3fCdra/0FPDczlWzKB+8Mbl2XZn edw0LORJB/3Z1t8eNJPzBe6TYMRUw9E4DxuVLdvU89PEYBQynru345BsLUAV10uOiaIw nNj7nD9K/1KBTwsreOO6oVcyCLkfGpKQBbvKTkVG9wtM4BqueGZU+lc0m/wpWO5d4Aoi abLKUwAavriJQry6X5BrqZ65A0VkarH3b9v6tmHcZGPIp23qTzhDY+fWqYK0RlbVbQba b7rQ== X-Gm-Message-State: AO0yUKXPwTL4z6ZEqSjIHybJw12rsHRUfSZRjq9am2OcJvw6xcZWOfWk N4bgF6Ud6iWb30I3qiC9HseOFApoucCJI62+/Fkjw+ON6kzgWg== X-Google-Smtp-Source: AK7set+j3LRS8pE0B99inqkmNLdi24mQyc4UWYS6FzXD3cdMC0b1LwR7dY5K/mULTGuvZL8gpvNblX5TE4h9HiWRDLE= X-Received: by 2002:adf:df11:0:b0:2c4:8bd:60dc with SMTP id y17-20020adfdf11000000b002c408bd60dcmr183869wrl.634.1676028314757; Fri, 10 Feb 2023 03:25:14 -0800 (PST) List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org MIME-Version: 1.0 References: <20230208190833.1DF6F8824@freefall.freebsd.org> In-Reply-To: From: Mariusz Zaborski Date: Fri, 10 Feb 2023 12:25:03 +0100 Message-ID: Subject: Re: FreeBSD Security Advisory FreeBSD-SA-23:01.geli To: Mel Pilgrim Cc: freebsd-security@freebsd.org, FreeBSD Security Advisories Content-Type: multipart/alternative; boundary="00000000000055af1205f456c0c7" X-Rspamd-Queue-Id: 4PCrxm2LJWz3spg X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000055af1205f456c0c7 Content-Type: text/plain; charset="UTF-8" To test decryption in dry mode (can be used on the decrypted device): echo -n | geli attach -C -p -k - dev If it succeeds you want to re-encrypt your devices. On Fri, 10 Feb 2023 at 02:48, Mel Pilgrim wrote: > On 2023-02-08 11:08, FreeBSD Security Advisories wrote: > > > ============================================================================= > > FreeBSD-SA-23:01.geli Security > Advisory > > The FreeBSD > Project > > > > Topic: GELI silently omits the keyfile if read from stdin > > How do I test my existing devices to see if the master key needs to be > encrypted? > > Does the solution change if the keyfiles don't require passwords? I use > GELI keyfiles without passwords for unattended reboots. > > --00000000000055af1205f456c0c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To test decryption in dry mode (can be used on the decrypt= ed device):
echo -n | geli attach -C -p -k - dev

If it succeeds y= ou want to re-encrypt your devices.

On Fri, 10 Feb 2023 at 02:48, Mel Pilgri= m <li= st_freebsd@bluerosetech.com> wrote:
On 2023-02-08 11:08, FreeBSD Security Advisories= wrote:
> =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-23:01.geli=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Security Advisory
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The Free= BSD Project
>
> Topic:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 GELI silently omits the keyfi= le if read from stdin

How do I test my existing devices to see if the master key needs to be
encrypted?

Does the solution change if the keyfiles don't require passwords?=C2=A0= I use
GELI keyfiles without passwords for unattended reboots.

--00000000000055af1205f456c0c7--