From owner-freebsd-security@freebsd.org Fri Dec 11 20:23:23 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 108224BA001 for ; Fri, 11 Dec 2020 20:23:23 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ct2Kk17zxz4rLy for ; Fri, 11 Dec 2020 20:23:21 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BBKNF17008868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Dec 2020 15:23:20 -0500 Date: Fri, 11 Dec 2020 12:23:15 -0800 From: Benjamin Kaduk To: Andrea Venturoli Cc: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl Message-ID: <20201211202315.GK64351@kduck.mit.edu> References: <20201209230300.03251CA1@freefall.freebsd.org> <0ccfbeb4-c4e1-53e6-81e8-112318cd9bf1@netfence.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0ccfbeb4-c4e1-53e6-81e8-112318cd9bf1@netfence.it> X-Rspamd-Queue-Id: 4Ct2Kk17zxz4rLy X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kaduk@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=kaduk@mit.edu X-Spamd-Result: default: False [-1.30 / 15.00]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[18.9.28.11:from]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[mit.edu]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-security]; RECEIVED_SPAMHAUS_PBL(0.00)[24.16.140.251:received] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2020 20:23:23 -0000 On Fri, Dec 11, 2020 at 11:11:54AM +0100, Andrea Venturoli wrote: > On 12/10/20 12:03 AM, FreeBSD Security Advisories wrote: > > > Note: The OpenSSL project has published publicly available patches for > > versions included in FreeBSD 12.x. This vulnerability is also known to > > affect OpenSSL versions included in FreeBSD 11.4. However, the OpenSSL > > project is only giving patches for that version to premium support contract > > holders. The FreeBSD project does not have access to these patches and > > recommends FreeBSD 11.4 users to either upgrade to FreeBSD 12.x or leverage > > up to date versions of OpenSSL in the ports/pkg system. The FreeBSD Project > > may update this advisory to include FreeBSD 11.4 should patches become > > publicly available. > > So I'm looking for suggestion on how to handle this. > I guess I'll just upgrade some 11.4 to 12.2 and that'll be it. > > However there are a few boxes I can't or don't want to upgrade and I'm > thinking about using openssl from ports. > > > > If I'm correct, I'll need to put "DEFAULT_VERSIONS= ssl=openssl" either > in /etc/make.conf and/or in /usr/local/etc/poudriere.d/114amd64-make.conf. > > I started with the latter, but a bulk run ended up in some port failing > (and a lot being skipped) due to kerberos support: AFAICT I cannot use > base's kerberos with ports' openssl. Which is a better replacement: MIT > or HEIMDAL? It would be useful to give more specifics on the failures, as there's a few classes of things that can go wrong. It doesn't look like openssl from ports attempts to support the TLS ciphers with kerberos, which would rule out the "openssl tries to depend on kerberos" class of issues. I assume, then, that you're running into API conflicts where hcrypto and libcrypto present similar-named symbols, in which case MIT would be preferred. (The heimdal in base is quite old anyway, and using an external kerberos would be recommended in general if you're using it for much.) -Ben