From owner-freebsd-security@freebsd.org Tue Dec 22 19:47:09 2015 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7BFEA4F9ED for ; Tue, 22 Dec 2015 19:47:09 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 C123A1030 for ; Tue, 22 Dec 2015 19:47:09 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id C879220776 for ; Tue, 22 Dec 2015 14:47:08 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Tue, 22 Dec 2015 14:47:08 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=iT5VtJGvLSqglKp 5H0wum1nbV74=; b=jL7hEVAhnEYZGA+EUh0Glb2haZkbholEpTfPhuZ/lHxZqCf 4yaHwe8JKzQH6b7Y+jARXNHXb6Ij+EMwFdm+LSrdU+rUc7WKCvdEyGBfi/pYSUBS eAVNqjg9xW32jrhRnyvC0qqBfblDakUzL2vUwAfI2vq66fT88YcfHzmgyeoQ= Received: by web3.nyi.internal (Postfix, from userid 99) id 9CA4410869B; Tue, 22 Dec 2015 14:47:08 -0500 (EST) Message-Id: <1450813628.928199.474310569.10D06284@webmail.messagingengine.com> X-Sasl-Enc: BCORaDW7ptR5zP626e0KHGGiviUWrnFe61vHYfZnxpkO 1450813628 From: Mark Felder To: Roger Marquis , freebsd-security@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-a93c17cb Subject: Re: [OpenSSL] /etc/ssl/cert.pem not honoured by default Date: Tue, 22 Dec 2015 13:47:08 -0600 In-Reply-To: References: <5673FB3B.2010201@freebsd.org> <5674364A.7090600@infracaninophile.co.uk> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 19:47:10 -0000 On Fri, Dec 18, 2015, at 16:21, Roger Marquis wrote: > rhi wrote: > >> Until now, I have avoided installing the OpenSSL port because the base > >> OpenSSL gets security updates via freebsd-update and so it's one thing less > >> to care about... also, I don't like the idea of having two different > >> versions of the same thing on the system > > A fair number of sites have this issue, particularly with ssl and ssh > binaries. IME this one of FreeBSD's more longstanding administrative and > security weaknesses. It is paricularly painful for those of us who have > to support a release for several years (after the last base update). > > >> Or is it recommended to let ports use the port OpenSSL, so that base OpenSSL > >> is only used for the system itself? > > If you need the most recent ciphers and protocols you'll normally need to > use the port. Features are backported from the (higher) port version to > the base version i.e., without bumping the version string, however, it's > not clear whether all applications can take advantage of them. > > Matthew Seaman wrote: > > There are plans to make many of the base system shlibs private and that > > includes switching the ports to use openssl from ports, but I don't think > > any changes along those lines are really imminent. > > Are you Sure? 3 months ago DES thought they'd be ready for 11: > > > The plan is for 11 to have a fully packaged base system. There should > > be some information in developer summit reports on the wiki. The code > > is in projects/release-pkg. > > However I don't see a projects/release-pkg dir in -CURRENT. > > Any recommendations as to how we might help this particular effort? > What do you mean? It has been there for a while https://svnweb.freebsd.org/base/projects/release-pkg/ -- Mark Felder ports-secteam member feld@FreeBSD.org From owner-freebsd-security@freebsd.org Wed Dec 23 08:39:17 2015 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30C65A4FD08 for ; Wed, 23 Dec 2015 08:39:17 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id ECFC81C81 for ; Wed, 23 Dec 2015 08:39:16 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 3F63EE92F; Wed, 23 Dec 2015 08:39:16 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id 6C9D2A7E7; Wed, 23 Dec 2015 09:39:08 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Roger Marquis Cc: freebsd-security@freebsd.org Subject: Re: [OpenSSL] /etc/ssl/cert.pem not honoured by default References: <5673FB3B.2010201@freebsd.org> <5674364A.7090600@infracaninophile.co.uk> <20151218222638.0F0EFE3B9@smtp.des.no> Date: Wed, 23 Dec 2015 09:39:08 +0100 In-Reply-To: <20151218222638.0F0EFE3B9@smtp.des.no> (Roger Marquis's message of "Fri, 18 Dec 2015 14:21:04 -0800 (PST)") Message-ID: <86wps5ftjn.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 08:39:17 -0000 Roger Marquis writes: > Matthew Seaman wrote: > > There are plans to make many of the base system shlibs private and that > > includes switching the ports to use openssl from ports, but I don't thi= nk > > any changes along those lines are really imminent. > > Are you Sure? 3 months ago DES thought they'd be ready for 11: > > > The plan is for 11 to have a fully packaged base system. There should > > be some information in developer summit reports on the wiki. The code > > is in projects/release-pkg. These are two different things. What Matthew is talking about is already well under way and has been since before 10: % tar tf 9.0/FreeBSD-9.0-RELEASE-amd64-disc1.iso | egrep -w 'lib(private)?s= sh' usr/lib/libssh.a usr/lib/libssh.so.5 usr/lib32/libssh.a usr/lib32/libssh.so.5 usr/lib32/libssh.so usr/lib/libssh.so % tar tf 9.3/FreeBSD-9.3-RELEASE-amd64-disc1.iso | egrep -w 'lib(private)?s= sh' usr/lib/private/libssh.a usr/lib/private/libssh.so.5 usr/lib/private/libssh.so % tar tf 10.0/FreeBSD-10.0-RELEASE-amd64-disc1.iso | egrep -w 'lib(private)= ?ssh' usr/lib/private/libssh.a usr/lib/private/libssh.so.5 usr/lib/private/libssh.so % tar tf 11.0/FreeBSD-11.0-CURRENT-amd64-20151102-r290273-disc1.iso | egrep= -w 'lib(private)?ssh'=20 usr/lib/libprivatessh.a usr/lib/libprivatessh.so.5 usr/lib/libprivatessh.so DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@freebsd.org Sat Dec 26 14:49:34 2015 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E8C0A5275F for ; Sat, 26 Dec 2015 14:49:34 +0000 (UTC) (envelope-from def@FreeBSD.org) Received: from mail1.uj.edu.pl (mail1.uj.edu.pl [149.156.89.193]) by mx1.freebsd.org (Postfix) with ESMTP id DC9AC13B8; Sat, 26 Dec 2015 14:49:33 +0000 (UTC) (envelope-from def@FreeBSD.org) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.1.48] ([83.5.161.83]) by mta.uoks.uj.edu.pl (Oracle Communications Messaging Server 7u4-27.01 (7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0NZY00A2FZUCNP00@mta.uoks.uj.edu.pl>; Sat, 26 Dec 2015 15:49:25 +0100 (CET) To: freebsd-security@FreeBSD.org Cc: Pawel Jakub Dawidek From: Konrad Witaszczyk Subject: Encrypted kernel crash dumps. Message-id: <567EA8F4.6020707@FreeBSD.org> Date: Sat, 26 Dec 2015 15:49:24 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.6 at clamav1 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2015 14:49:34 -0000 Dear FreeBSD Community, I posted a review of a patch containing encrypted kernel crash dumps feature. You can find the review here: https://reviews.freebsd.org/D4712 . Kernel crash dumps contain information about currently running processes. They can include sensitive data, for example passwords kept in memory by a browser when a kernel panic occurred. A person who can read data from a dump device or a crash directory can also extract these information from a core dump. In order to prevent this situation the core dump should be encrypted before it is stored on the dump device. Changes include modifications in kernel crash dump routines, dumpon(8) and savecore(8). A new tool called decryptcore(8) was added. Below you can find details on the changes. A new DIOCSKERNELDUMP I/O control was added to send a kernel crash dump configuration in the diocskerneldump_arg structure to the kernel. The old DIOCSKERNELDUMP I/O control was renamed to DIOCSKERNELDUMPOLD for backward ABI compatibility. dumpon(8) generates an one-time random symmetric key and encrypts it using an RSA public key in capability mode. Currently only AES-256-CBC is supported but EKCD was designed to implement support for other algorithms in the future. The public key is chosen using the -k flag. The dumpon rc(8) script can do this automatically during startup using the dumppubkey rc.conf(5) variable. Once the keys are calculated dumpon sends them to the kernel via DIOCSKERNELDUMP I/O control. When the kernel receives the DIOCSKERNELDUMP I/O control it generates a random IV and sets up the key schedule for the specified algorithm. Each time the kernel tries to write a crash dump to the dump device, the IV is replaced by a SHA-256 hash of the previous value. This is intended to make a possible differential cryptanalysis harder. A kernel dump key consists of an algorithm identifier, an IV and an encrypted symmetric key. The kernel dump key size is included in a kernel dump header. The size is an unsigned 32-bit integer and it is aligned to a block size. The header structure has 512 bytes to match the block size so it was required to make a panic string 4 bytes shorter to add a new field to the header structure. If the kernel dump key size in the header is nonzero it is assumed that the kernel dump key is placed after the first header on the dump device and the core dump is encrypted. Separate functions were implemented to write the kernel dump header and the kernel dump key as they need to be unencrypted. The dump_write function encrypts data if the kernel was compiled with the EKCD option. Encrypted kernel textdumps are not supported due to the way they are constructed which makes it impossible to use the CBC mode for encryption. savecore(8) writes the kernel dump key to a key.# file if its size in the header is nonzero. # is the number of the current core dump. decryptcore(8) decrypts the core dump using a private RSA key and the kernel dump key. This is performed by a child process in capability mode. If the decryption was not successful the parent process removes a partially decrypted core dump. Description on how to encrypt crash dumps was added to the decryptcore(8), dumpon(8), rc.conf(5) and savecore(8) manual pages. I would like to thank Pawel Jakub Dawidek for the support and time spent on discussing the design and implementation of this project. Best regards, Konrad Witaszczyk