From owner-freebsd-security@FreeBSD.ORG Sun Nov 2 20:02:24 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA99C1C5 for ; Sun, 2 Nov 2014 20:02:24 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 A3483D4F for ; Sun, 2 Nov 2014 20:02:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id sA2K2Odt066855 for ; Sun, 2 Nov 2014 20:02:24 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id sA2K2O7H066850 for freebsd-security@FreeBSD.org; Sun, 2 Nov 2014 20:02:24 GMT (envelope-from bdrewery) Received: (qmail 5280 invoked from network); 2 Nov 2014 14:02:20 -0600 Received: from unknown (HELO blah) (freebsd@shatow.net@129.253.54.225) by sweb.xzibition.com with ESMTPA; 2 Nov 2014 14:02:20 -0600 Message-ID: <54568DA2.6030309@FreeBSD.org> Date: Sun, 02 Nov 2014 14:01:38 -0600 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-ports@FreeBSD.org Subject: SSP now default for ports/packages, ssp/new_xorg repository EOL Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 02 Nov 2014 20:07:56 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 20:02:24 -0000 Ports and Package users, Ports now have SSP enabled by default. The package repository will now build SSP by default as well. SSP is "Stack Smashing Protection" and can be read about at https://en.wikipedia.org/wiki/Buffer_overflow_protection. This only applies to the head (/latest) packages, not the Quarterly branch packages. This applies to the ports checkout that portsnap uses. WITHOUT_SSP can be defined in make.conf to not use this feature. SSP will be used to build ports (with -fstack-protector) on all amd64 releases and i386 releases which are 10.0 or newer. The "ssp" repository and "new_xorg" repositories will no longer be updated after 11/15 as they are no longer needed as both are default for ports now. Please update your repository configurations to now only track the /latest repository. This is the default from /etc/pkg/FreeBSD.conf. Remove any overrides from /usr/local/etc/pkg/repos/ for the "ssp" or "new_xorg" repositories. Regards, Bryan Drewery on behalf of portmgr From owner-freebsd-security@FreeBSD.ORG Wed Nov 5 00:43:22 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3FFD12F; Wed, 5 Nov 2014 00:43:22 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 6BB7AC21; Wed, 5 Nov 2014 00:43:22 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id C7EAFAF82; Wed, 5 Nov 2014 00:43:21 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id B463110ED; Wed, 5 Nov 2014 01:43:20 +0100 (CET) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:24.sshd Reply-To: freebsd-security@freebsd.org Precedence: bulk Message-Id: <20141105004320.B463110ED@nine.des.no> Date: Wed, 5 Nov 2014 01:43:20 +0100 (CET) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 00:43:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:24.sshd Security Advisory The FreeBSD Project Topic: Denial of service attack against sshd(8) Category: contrib Module: openssh Announced: 2014-11-04 Credits: Affects: FreeBSD 9.1, 9.2 and 10.0. Corrected: 2014-05-04 07:28:26 UTC (stable/10, 10.0-STABLE) 2014-11-04 23:31:17 UTC (releng/10.0, 10.0-RELEASE-p12) 2014-05-04 07:57:20 UTC (stable/9, 9.2-STABLE) 2014-11-04 23:33:17 UTC (releng/9.2, 9.2-RELEASE-p15) 2014-11-04 23:32:45 UTC (releng/9.1, 9.1-RELEASE-p22) CVE Name: CVE-2014-8475 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background OpenSSH is an implementation of the SSH protocol suite, providing an encrypted and authenticated transport for a variety of services, including remote shell access. The sshd(8) daemon is the server side of OpenSSH. Heimdal is an implementation of Kerberos 5, which provides authentication and single sign-on capability for many network services, including OpenSSH. II. Problem Description Although OpenSSH is not multithreaded, when OpenSSH is compiled with Kerberos support, the Heimdal libraries bring in the POSIX thread library as a dependency. Due to incorrect library ordering while linking sshd(8), symbols in the C library which are shadowed by the POSIX thread library may not be resolved correctly at run time. Note that this problem is specific to the FreeBSD build system and does not affect other operating systems or the version of OpenSSH available from the FreeBSD ports tree. III. Impact An incorrectly linked sshd(8) child process may deadlock while handling an incoming connection. The connection may then time out or be interrupted by the client, leaving the deadlocked sshd(8) child process behind. Eventually, the sshd(8) parent process stops accepting new connections. An attacker may take advantage of this by repeatedly connecting and then dropping the connection after having begun, but not completed, the authentication process. IV. Workaround Possible workarounds include rebuilding sshd with Kerberos support disabled or installing the security/openssh-portable package from the FreeBSD ports tree or an official package repository. Systems that do not run an OpenSSH server are not affected. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install 3) 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 http://security.FreeBSD.org/patches/SA-14:24/sshd.patch # fetch http://security.FreeBSD.org/patches/SA-14:24/sshd.patch.asc # gpg --verify sshd.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/sshd.patch c) Recompile sshd. Execute the following commands as root: # cd /usr/src/secure/usr.sbin/sshd # make && make install 4) Restart the affected service To restart the affected service after updating the system, either reboot the system or execute the following command as root: # service sshd restart VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/9/ r265314 releng/9.1/ r274112 releng/9.2/ r274113 stable/10/ r265313 releng/10.0/ r274110 - ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # 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----- iQIcBAEBCgAGBQJUWWlZAAoJEO1n7NZdz2rn4UEP/0VdM6uSHWyQSOzO+kuDxRfT wru9+yjCB4NJtFzvBLe8eeiUDiTqJaTfrAGbbr9l5qkRXvTaUzWyaHyraLN4nK51 /ouxKzxxrqf0YDpYQPIUwCVmkoLn/+0T3U7sB78bx5WH4W1XoKKWIkChCyZpVvBI vw6A5Ep4+U6mTGXE2D04WQISkKXYqzCuW0rJBnm0xDj9xUprgZJ7tTSx/ewAiA/L FV37riqb8OII8lThV7g0s0F0JWDUf+AznG/S7amior0jMMSExdafifcvHEUZNs72 4cYh66p/GxeImU2Tm3VDRlfoAv86kUFwIevwD4oj5wXa7aBMdUwPITyQJ0We68gj 3kMBpJaZAJ7DpwYuCu7/RF7K4Irt3mSJJipS3IvI2LteHCakZBIUlbrPJrcfMl4P VJQU3v4HLH5XZskuR5UEJ755DT+7ZMd7tFl0iWFVsutwjf/bn2u0rtfdcpOerAub 0gYGzPcC9dzBM5OHZdo1wwmZu56jRpddmQ/nc94Wsmm7Nw2ibd9YZpU88LCqR7xa jsW+F/+napKvsBXqAHTlmJ87oJUSruYS+K/dKbGvCDIjBTjsNu3HqMNS5g4vG+GR MazlN8Vrg6zVx11ESzFiIJBAgLLNfRgXNFNSPY3NMuMYiS7q0QwGkQlWBb5bmiB8 FlP/B/8bn/171n5RfarG =mry5 -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed Nov 5 00:43:39 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A52A45C2; Wed, 5 Nov 2014 00:43:39 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 43C39C42; Wed, 5 Nov 2014 00:43:38 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 3CBB1AF86; Wed, 5 Nov 2014 00:43:38 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 19DA010F9; Wed, 5 Nov 2014 01:43:37 +0100 (CET) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:25.setlogin Reply-To: freebsd-security@freebsd.org Precedence: bulk Message-Id: <20141105004337.19DA010F9@nine.des.no> Date: Wed, 5 Nov 2014 01:43:37 +0100 (CET) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 00:43:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:25.setlogin Security Advisory The FreeBSD Project Topic: Kernel stack disclosure in setlogin(2) / getlogin(2) Category: core Module: kernel Announced: 2014-11-04 Credits: Mateusz Guzik Affects: All supported versions of FreeBSD. Corrected: 2014-11-04 23:29:57 UTC (stable/10, 10.1-PRERELEASE) 2014-11-04 23:34:46 UTC (releng/10.1, 10.1-RC4-p1) 2014-11-04 23:34:46 UTC (releng/10.1, 10.1-RC3-p1) 2014-11-04 23:34:46 UTC (releng/10.1, 10.1-RC2-p3) 2014-11-04 23:31:17 UTC (releng/10.0, 10.0-RELEASE-p12) 2014-11-04 23:30:47 UTC (stable/9, 9.3-STABLE) 2014-11-04 23:33:46 UTC (releng/9.3, 9.3-RELEASE-p5) 2014-11-04 23:33:17 UTC (releng/9.2, 9.2-RELEASE-p15) 2014-11-04 23:32:45 UTC (releng/9.1, 9.1-RELEASE-p22) 2014-11-04 23:30:23 UTC (stable/8, 8.4-STABLE) 2014-11-04 23:32:15 UTC (releng/8.4, 8.4-RELEASE-p19) CVE Name: CVE-2014-8476 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The setlogin(2) system call sets the login name of the user associated with the current session. The getlogin(2) routine returns the login name of the user associated with the current session, as previously set by setlogin(2). II. Problem Description When setlogin(2) is called while setting up a new login session, the login name is copied into an uninitialized stack buffer, which is then copied into a buffer of the same size in the session structure. The getlogin(2) system call returns the entire buffer rather than just the portion occupied by the login name associated with the session. III. Impact An unprivileged user can access this memory by calling getlogin(2) and reading beyond the terminating NUL character of the resulting string. Up to 16 (FreeBSD 8) or 32 (FreeBSD 9 and 10) bytes of kernel memory may be leaked in this manner for each invocation of setlogin(2). This memory may contain sensitive information, such as portions of the file cache or terminal buffers, which an attacker might leverage to obtain elevated privileges. IV. Workaround No workaround is available. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install 3) 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. [FreeBSD 9.1] # fetch http://security.FreeBSD.org/patches/SA-14:25/setlogin-91.patch # fetch http://security.FreeBSD.org/patches/SA-14:25/setlogin-91.patch.asc # gpg --verify setlogin-91.patch.asc [All other versions] # fetch http://security.FreeBSD.org/patches/SA-14:25/setlogin.patch # fetch http://security.FreeBSD.org/patches/SA-14:25/setlogin.patch.asc # gpg --verify setlogin.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 The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/8/ r274108 releng/8.4/ r274111 stable/9/ r274109 releng/9.1/ r274112 releng/9.2/ r274113 releng/9.3/ r274114 stable/10/ r274107 releng/10.0/ r274110 releng/10.1/ r274115 - ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # 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----- iQIcBAEBCgAGBQJUWWUQAAoJEO1n7NZdz2rnI0IP/RlwFhOJgr9CHdKg5SYsruSQ LG6z0ufgUETIkeXP1KGm6oYz0X8hpU2Q+MIE5urrPbGYL4Ouo/1oCiwGkBPh4xM/ L2Z/qIBxmfG/NaRK8PnGSXzlCc02XGnqf9Y6CJN1sIkwrptop02y9sgaLsqLy7K6 s/YvQ1fe5FT6TV9Nr9l6OwKkVAYa1Ba+JUnklVBWA2eZkLa6YOUlY25w9alqTMVQ Z4oaLHCnGradKdaKKk0NOOYv0ZGHjkp/Lwd9ja8wyW0K+R1aef9Z5tWloVWQBeJ8 gzxeA/JpfRtb0lYj2GIpny6znP/lzkEve42No6xDdmUr4Wp0b5hN2qGgwwgEFSIo 2kFVwMkRlK1JsD0U+VK8AxP4neJFECw3t0zWTUr3BMnxoOEG6O1nIU0T6Ru8/K0b aIc/G8TiOxOaXHuiWJhR1p9cblGlz7HnFSAmM6vN0O4DBcX7xwr/ndDl/6npvkmt biB+hXZK0Ega8X9LsZ5injDo0FZ4XNIyEOy4/QOeJW4kJQv0Oh14cYSU6cM/yfaU tJ7M6WYnFS8G+0e03auM1XVeu2oxyR0ry1IC7xS4O9N4m+8nE7DlRU8okhQRXiFB iCmzO1XmOTK0zygtS34bDaOuey3U0yFG4O5wMKrAkMeQ9jPogyt99ZzIk3L3UPqZ xcWRhKahyz9umrzsssOL =xiWR -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed Nov 5 00:43:47 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A805898C; Wed, 5 Nov 2014 00:43:47 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 4E41AC58; Wed, 5 Nov 2014 00:43:47 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 91D3FAF8B; Wed, 5 Nov 2014 00:43:46 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 5478C1104; Wed, 5 Nov 2014 01:43:45 +0100 (CET) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:26.ftp Reply-To: freebsd-security@freebsd.org Precedence: bulk Message-Id: <20141105004345.5478C1104@nine.des.no> Date: Wed, 5 Nov 2014 01:43:45 +0100 (CET) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 00:43:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:26.ftp Security Advisory The FreeBSD Project Topic: Remote command execution in ftp(1) Category: core Module: ftp Announced: 2014-11-04 Credits: Jared McNeill, Alistair Crooks Affects: All supported versions of FreeBSD. Corrected: 2014-11-04 23:29:57 UTC (stable/10, 10.1-PRERELEASE) 2014-11-04 23:34:46 UTC (releng/10.1, 10.1-RC4-p1) 2014-11-04 23:34:46 UTC (releng/10.1, 10.1-RC3-p1) 2014-11-04 23:34:46 UTC (releng/10.1, 10.1-RC2-p3) 2014-11-04 23:31:17 UTC (releng/10.0, 10.0-RELEASE-p12) 2014-11-04 23:30:47 UTC (stable/9, 9.3-STABLE) 2014-11-04 23:33:46 UTC (releng/9.3, 9.3-RELEASE-p5) 2014-11-04 23:33:17 UTC (releng/9.2, 9.2-RELEASE-p15) 2014-11-04 23:32:45 UTC (releng/9.1, 9.1-RELEASE-p22) 2014-11-04 23:30:23 UTC (stable/8, 8.4-STABLE) 2014-11-04 23:32:15 UTC (releng/8.4, 8.4-RELEASE-p19) CVE Name: CVE-2014-8517 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The ftp(1) userland utility is an interactive FTP client. It can also be used non-interactively, by providing a URL on the command line. In this mode, it supports HTTP in addition to FTP. II. Problem Description A malicious HTTP server could cause ftp(1) to execute arbitrary commands. III. Impact When operating on HTTP URIs, the ftp(1) client follows HTTP redirects, and uses the part of the path after the last '/' from the last resource it accesses as the output filename if '-o' is not specified. If the output file name provided by the server begins with a pipe ('|'), the output is passed to popen(3), which might be used to execute arbitrary commands on the ftp(1) client machine. IV. Workaround No workaround is available. Users are encouraged to replace ftp(1) in non-interactive use by either fetch(1) or a third-party client such as curl or wget. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install 3) 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. [FreeBSD 8] # fetch http://security.FreeBSD.org/patches/SA-14:26/ftp-8.patch # fetch http://security.FreeBSD.org/patches/SA-14:26/ftp-8.patch.asc # gpg --verify ftp-8.patch.asc [All other versions] # fetch http://security.FreeBSD.org/patches/SA-14:26/ftp.patch # fetch http://security.FreeBSD.org/patches/SA-14:26/ftp.patch.asc # gpg --verify ftp.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile ftp. Execute the following commands as root: # cd /usr/src/usr.bin/ftp # make && make install VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/8/ r274108 releng/8.4/ r274111 stable/9/ r274109 releng/9.1/ r274112 releng/9.2/ r274113 releng/9.3/ r274114 stable/10/ r274107 releng/10.0/ r274110 releng/10.1/ r274115 - ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # 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----- iQIcBAEBCgAGBQJUWWUQAAoJEO1n7NZdz2rnhUwP+wQKrgKs6lRk6Yl4UtRyEwyG BHGkA62oaQbehuccahjQgIcLTk3Vp3AalXtSQpdyWJktHiYrFwBnheW/IrhJ6bMS dpJv3yqqQtSED9sADf+GAvxV6TG9bknq/RDxXKpsQ/MocYbiVxz/3nDOMz9CB7ep saDttvGHW7RUmNoKL70pgItGapiVuBzMF01PCZ2SmFiJHYi7BoiJwm72Y1NLU8YE TkiX2ZAoTVMN5/R3DW38HyVCyeY2tMTHSdQXRSYjwzJ0gEbBPWMPQyB1SAa8dtk5 j54KFNOBoaXMjd3USqFgo0fduU3rGZp5PwITTx5Rx5Ixtz2vHddyOISV0RcjA0cq TWDwBGlKET7qZ1j7nHTgy4U4wMTWFbkjjqEY+RHYywaAmy8ACDmEUci8d3fWKWVY d4y8RCvBrlnFVjmNiNcBc5XFXxY0Ra3BQ8C/VE0k0ZFuzmFUCi+DJZDR2Gtl0R9Q 1hAdj+yOJo46ylHPiSyoBZmsRZccV1a81phOPe0mPR84BvzNvBsdI+EFIJWi+5bw bjuSM8YCOHrlGkqh9h9+BizvLfJFpjUSglwzPmOfRpTv59XJpc6D1Hia+uICTEfd lSiJgDZ6enozY7QVoiO7G/ycyQCVe7Ehwywx/dpWXVpva85tn4Xl2khBCiPNbBBo xnPjqxmwGK+4uegsO6CY =QT3h -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Thu Nov 6 23:48:57 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DF52590; Thu, 6 Nov 2014 23:48:57 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 5988875; Thu, 6 Nov 2014 23:48:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id sA6NmvAG073495; Thu, 6 Nov 2014 23:48:57 GMT (envelope-from security-advisories@freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id sA6Nmv9q073493; Thu, 6 Nov 2014 23:48:57 GMT (envelope-from security-advisories@freebsd.org) Date: Thu, 6 Nov 2014 23:48:57 GMT Message-Id: <201411062348.sA6Nmv9q073493@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: delphij set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:24.sshd [REVISED] Reply-To: freebsd-security@freebsd.org Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 23:48:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:24.sshd Security Advisory The FreeBSD Project Topic: Denial of service attack against sshd(8) Category: contrib Module: openssh Announced: 2014-11-04 Credits: Konstantin Belousov Affects: FreeBSD 9.1, 9.2 and 10.0. Corrected: 2014-05-04 07:28:26 UTC (stable/10, 10.0-STABLE) 2014-11-04 23:31:17 UTC (releng/10.0, 10.0-RELEASE-p12) 2014-05-04 07:57:20 UTC (stable/9, 9.2-STABLE) 2014-11-04 23:33:17 UTC (releng/9.2, 9.2-RELEASE-p15) 2014-11-04 23:32:45 UTC (releng/9.1, 9.1-RELEASE-p22) CVE Name: CVE-2014-8475 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . 0. Revision History v1.0 2014-11-04 Initial release. v1.1 2014-11-06 Corrected "Credits" which was forgotten in the initial release, and corrected manual patch steps in "Solution" section. I. Background OpenSSH is an implementation of the SSH protocol suite, providing an encrypted and authenticated transport for a variety of services, including remote shell access. The sshd(8) daemon is the server side of OpenSSH. Heimdal is an implementation of Kerberos 5, which provides authentication and single sign-on capability for many network services, including OpenSSH. II. Problem Description Although OpenSSH is not multithreaded, when OpenSSH is compiled with Kerberos support, the Heimdal libraries bring in the POSIX thread library as a dependency. Due to incorrect library ordering while linking sshd(8), symbols in the C library which are shadowed by the POSIX thread library may not be resolved correctly at run time. Note that this problem is specific to the FreeBSD build system and does not affect other operating systems or the version of OpenSSH available from the FreeBSD ports tree. III. Impact An incorrectly linked sshd(8) child process may deadlock while handling an incoming connection. The connection may then time out or be interrupted by the client, leaving the deadlocked sshd(8) child process behind. Eventually, the sshd(8) parent process stops accepting new connections. An attacker may take advantage of this by repeatedly connecting and then dropping the connection after having begun, but not completed, the authentication process. IV. Workaround Possible workarounds include rebuilding sshd with Kerberos support disabled or installing the security/openssh-portable package from the FreeBSD ports tree or an official package repository. Systems that do not run an OpenSSH server are not affected. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install 3) 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 http://security.FreeBSD.org/patches/SA-14:24/sshd.patch # fetch http://security.FreeBSD.org/patches/SA-14:24/sshd.patch.asc # gpg --verify sshd.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/sshd.patch c) Recompile sshd. Execute the following commands as root: # cd /usr/src/secure/usr.sbin/sshd # make clean # make obj && make depend && make && make install 4) Restart the affected service To restart the affected service after updating the system, either reboot the system or execute the following command as root: # service sshd restart VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/9/ r265314 releng/9.1/ r274112 releng/9.2/ r274113 stable/10/ r265313 releng/10.0/ r274110 - ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # 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----- iQIcBAEBCgAGBQJUXASgAAoJEO1n7NZdz2rnWyAQALEtSzPI5tZFRI79lLO3c3yM 6i7l6eqI7xUgh22M3w7oEDGEB/g51BJC+5haM9+CfrHrXDKMF1L3vQ29SUT3tNd/ abFaG2DZW9EbmG0pTsJco+looPOSIwWuAthGQAEkAU2073iX2ldo7MUcUzhTHu8d 0lIIoruefY92e4datwhlJT+6LLnCphPX1vRlo8N9hZrB/LO5+e/1c6wSK4lgIxEc mMdoXx/heCtPiwL+O7iTqa2j4VzZDGy+v4jaFYIkI/WFvsYm+X+xzUxRiJIY+8o7 3LMtUSHXv+hlV8DVCjtbDevJt+h42K1CgL22vkgMvzyRMF8vM+Fk8Kvvfd3GL9d6 ZJGv1cNZarRwfbE5pB+4JaXHgFMj4lihmoJdKqgxYglMbrdtHZM4pzZ2xX0GlsPD Hf4f1r+DugPc43s7lU9zus75NaVh/DZnFEHCTV7qIo0DD4Ia+T5lZnyfjNvbY7W+ q3Yz+bn3Uq9VdWW1WRpvaFItRuVbJGhGSpcVWl+QJHg9+plnZ0RQMmalkIgP6LBd nhq5rWQlbwc3pM2RMefr29Yl3oCc5Ox/AUnV/DD+bEkFa61mlldtm2cRq3X6yaMW sXRJ22DDHP10aMzlq0MkIQcbrgycAnoj6WEGBinv+lqh8SxHTkNi3pRI1w5lSh+k 075uI0Ka6HINuYqtRUaI =C6El -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Fri Nov 7 21:06:51 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E24C87E; Fri, 7 Nov 2014 21:06:51 +0000 (UTC) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 137A1C75; Fri, 7 Nov 2014 21:06:51 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id hy10so2241913vcb.39 for ; Fri, 07 Nov 2014 13:06:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q8Bwf9rQwuFMx01aXD8aOzVraH2Q+lTxJLoP6htJ2dw=; b=m/Qoe9HIldtUqe1tl2UGTbANmZfpK9CC/Oa3Xz/9U9z78Y/oH/li1mrR/N7308HUlp Mj61xFBS6cpeQp2XxVg3Qo4bWok6upA93kzIPurOQ7A+xNQVhKR8XMwwoDds/nrw7TZ6 dcXL5B4qTV4z4mq7FeWYC8ZISwq3BQ8nPs+gFi7DK/2Ikgc7qD1aFKkAg9hcv0hZTgz6 r2dJr/TbPtocVfRKyUkYdS/2fv2BIOp1JFwlNgJhwjdYuCWvGtTW3SkYGM5u0VEEmqCp pTH6kuk4Z4oTwLIwh9nvUr8aR+q4J9tjWVqeFp97lAQUibpdQGQ6AOFarCc1/ucWG0Yw RQsg== MIME-Version: 1.0 X-Received: by 10.221.38.66 with SMTP id th2mr9320080vcb.21.1415394410134; Fri, 07 Nov 2014 13:06:50 -0800 (PST) Received: by 10.221.64.74 with HTTP; Fri, 7 Nov 2014 13:06:50 -0800 (PST) In-Reply-To: References: <20141106135228.GE3824@nymity.ch> Date: Fri, 7 Nov 2014 16:06:50 -0500 Message-ID: Subject: Re: [tor-relays] FreeBSD's global IP ID (was: Platform diversity in Tor network) From: grarpamp To: tor-relays@lists.torproject.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 07 Nov 2014 23:12:18 +0000 Cc: FreeBSD Net , freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 21:06:51 -0000 On Fri, Nov 7, 2014 at 11:31 AM, Adrian Chadd wrote: > ... that's .. odd. > > Let's poke the freebsd crypto and network stack people and ask. I > can't imagine why this is a problem anymore and we should default to > it being on. I don't think there's a crypto@ list, though security@ might represent. > The other thing you could do is have the tor port require > it be turned on before tor runs. That would not cover people who compile and use upstream Tor. Ideally, the Tor client could check for any system parameters it feels are critical before running, or simply delegate them and/or any parameters of lesser importance to platform specific guides on the Tor wiki. > On 7 November 2014 00:20, grarpamp wrote: >> On Thu, Nov 6, 2014 at 8:52 AM, Philipp Winter wrote: >>> >>> FreeBSD still seems to use globally incrementing IP IDs by default. >>> That's an issue as it leaks fine-grained information about how many >>> packets a relay's networking stack processes. (However, nobody >>> investigated the exact impact on Tor relays so far, which makes this a >>> FUD-heavy topic.) It looks like approximately 50 out of the 131 FreeBSD >>> relays I tested (38%) use global IP IDs. >>> >>> There's a sysctl variable called "net.inet.ip.random_id" which makes a >>> FreeBSD's IP ID behaviour random. FreeBSD relay operators should set >>> this to "1". >>> >>> Note that this issue was already discussed earlier this year in a thread >>> called "Lots of tor relays send out sequential IP IDs; please fix >>> that!". >> >> It's been default off since before it was a sysctl over a decade ago. >> Anyone know what the deal is with that? Some objection, or >> forgotten flag day, or oversight that really should be set to 1? >> https://svnweb.freebsd.org/base?view=revision&revision=133720 From owner-freebsd-security@FreeBSD.ORG Sat Nov 8 04:23:03 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 071ABE8D; Sat, 8 Nov 2014 04:23:03 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D045EB56; Sat, 8 Nov 2014 04:23:02 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sA84N0SF060073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2014 20:23:01 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sA84N071060072; Fri, 7 Nov 2014 20:23:00 -0800 (PST) (envelope-from jmg) Date: Fri, 7 Nov 2014 20:23:00 -0800 From: John-Mark Gurney To: freebsd-security@FreeBSD.org, current@FreeBSD.org Subject: CFR: AES-GCM and OpenCrypto work review Message-ID: <20141108042300.GA24601@funkthat.com> Mail-Followup-To: freebsd-security@FreeBSD.org, current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 07 Nov 2014 20:23:01 -0800 (PST) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 04:23:03 -0000 Hello, Over the last few months, I've been working on a project to add support for AES-GCM and AES-CTR modes to our OpenCrypto framework. The work is sponsored by The FreeBSD Foundation and Netgate. I plan on committing these patches early next week. If you need more time for review, please email me privately and I will make delay. The code has already been reviewed by Watson Ladd (the software crypto implementations) and Trevor Perrin (the aesni module part) and I have integrated these changes into the patch. There are two patches, one is the changes for OpenCrypto and the test framework. The other is the data files used by the test framework. The data is from NIST's CAVP program, and is about 20MB worth of test vectors. (I just realized, should we look at compressing these on disk?) Main patch (192KB): https://www.funkthat.com/~jmg/patches/aes.ipsec.5.patch Data files (~20MB): https://www.funkthat.com/~jmg/patches/aes.ipsec.5.testing.patch A list of notable changes in the patch: - Replacing crypto(4) w/ NetBSD's version + updates - Lots of man page updates, including CIOCFINDDEV and crypto(7) which adds specifics about restrictions on the modes. - Allow sane useage of both _HARDWARE and _SOFTWARE flags. - Add a timing safe bcmp for MAC comparision. - Add a software implementation of GCM that uses a four bit lookup table with parallelization. This algorithm is possibly vulnerable to timing attacks, but best known mitigation methods are used. Using a timing safe version is many times slower. - Added a CRYPTDEB macro that defaults to off. - Bring in some of OpenBSD's improvements to the OpenCrypto framework. - If an mbuf passed to the aesni module is only one segment, don't do a copy. This needs to be improved to support segmented buffers. - Remove the CRYPTO_F_REL flag. It was meaningless. It was used but did not change any behavior. - Add function crypto_mbuftoiov to convert an mbuf to an iov. This also converts the software crypto to only use iov's even for a simple linear buffer, and so simplifies the processing. - Add a dtrace probe for errors from the ioctl. - Add the CIOCCRYPTAEAD ioctl that allows userland processing (testing) of AES-GCM and future AEAD modes. Future improvements: - Support IV's longer than 12 bytes for GCM. - Make AES-NI support segmented buffers (iov or mbuf) so multisegmented inputs don't have to be copied. I know there are more fixes and future improvements, but can't think of them now. Ermal (eri) has patches that enable AES-GCM (and I believe AES-CTR) support for our IPsec. Once these patches have been committed, I'll work with him to integrate his patch. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-security@FreeBSD.ORG Sat Nov 8 18:44:05 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35C3F3D7; Sat, 8 Nov 2014 18:44:05 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id EC65ADF7; Sat, 8 Nov 2014 18:44:04 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 57E8AA160; Sat, 8 Nov 2014 18:43:57 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 3B21F1413; Sat, 8 Nov 2014 19:43:55 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: freebsd-security@FreeBSD.org Subject: Re: CFR: AES-GCM and OpenCrypto work review References: <20141108042300.GA24601@funkthat.com> Date: Sat, 08 Nov 2014 19:43:55 +0100 In-Reply-To: <20141108042300.GA24601@funkthat.com> (John-Mark Gurney's message of "Fri, 7 Nov 2014 20:23:00 -0800") Message-ID: <86tx29jzx0.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: current@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 18:44:05 -0000 John-Mark Gurney writes: > Over the last few months, I've been working on a project to add support > for AES-GCM and AES-CTR modes to our OpenCrypto framework. The work is > sponsored by The FreeBSD Foundation and Netgate. > > I plan on committing these patches early next week. If you need more > time for review, please email me privately and I will make delay. Please remember to bump __FreeBSD_version. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Sat Nov 8 20:45:40 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3F38F2C; Sat, 8 Nov 2014 20:45:40 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BCAFBAC3; Sat, 8 Nov 2014 20:45:40 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sA8Kjd61071201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Nov 2014 12:45:39 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sA8KjcPn071200; Sat, 8 Nov 2014 12:45:38 -0800 (PST) (envelope-from jmg) Date: Sat, 8 Nov 2014 12:45:38 -0800 From: John-Mark Gurney To: Vsevolod Stakhov Subject: Re: CFR: AES-GCM and OpenCrypto work review Message-ID: <20141108204538.GI24601@funkthat.com> Mail-Followup-To: Vsevolod Stakhov , freebsd-security@freebsd.org, current@freebsd.org References: <20141108042300.GA24601@funkthat.com> <545E6712.5060305@highsecure.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <545E6712.5060305@highsecure.ru> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 08 Nov 2014 12:45:39 -0800 (PST) Cc: freebsd-security@freebsd.org, current@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 20:45:41 -0000 Vsevolod Stakhov wrote this message on Sat, Nov 08, 2014 at 18:55 +0000: > On 08/11/14 04:23, John-Mark Gurney wrote: > > Hello, > > > > Over the last few months, I've been working on a project to add support > > for AES-GCM and AES-CTR modes to our OpenCrypto framework. The work is > > sponsored by The FreeBSD Foundation and Netgate. > > > > I plan on committing these patches early next week. If you need more > > time for review, please email me privately and I will make delay. > > > > The code has already been reviewed by Watson Ladd (the software crypto > > implementations) and Trevor Perrin (the aesni module part) and I have > > integrated these changes into the patch. > > > > There are two patches, one is the changes for OpenCrypto and the test > > framework. The other is the data files used by the test framework. > > The data is from NIST's CAVP program, and is about 20MB worth of test > > vectors. (I just realized, should we look at compressing these on > > disk?) > > > > Main patch (192KB): > > https://www.funkthat.com/~jmg/patches/aes.ipsec.5.patch > > > > Data files (~20MB): > > https://www.funkthat.com/~jmg/patches/aes.ipsec.5.testing.patch > > > > A list of notable changes in the patch: > > - Replacing crypto(4) w/ NetBSD's version + updates > > - Lots of man page updates, including CIOCFINDDEV and crypto(7) which > > adds specifics about restrictions on the modes. > > - Allow sane useage of both _HARDWARE and _SOFTWARE flags. > > - Add a timing safe bcmp for MAC comparision. > > - Add a software implementation of GCM that uses a four bit lookup > > table with parallelization. This algorithm is possibly vulnerable to > > timing attacks, but best known mitigation methods are used. Using > > a timing safe version is many times slower. > > - Added a CRYPTDEB macro that defaults to off. > > - Bring in some of OpenBSD's improvements to the OpenCrypto framework. > > - If an mbuf passed to the aesni module is only one segment, don't do > > a copy. This needs to be improved to support segmented buffers. > > - Remove the CRYPTO_F_REL flag. It was meaningless. It was used but > > did not change any behavior. > > - Add function crypto_mbuftoiov to convert an mbuf to an iov. This > > also converts the software crypto to only use iov's even for a simple > > linear buffer, and so simplifies the processing. > > - Add a dtrace probe for errors from the ioctl. > > - Add the CIOCCRYPTAEAD ioctl that allows userland processing (testing) > > of AES-GCM and future AEAD modes. > > > > Future improvements: > > - Support IV's longer than 12 bytes for GCM. > > - Make AES-NI support segmented buffers (iov or mbuf) so multisegmented > > inputs don't have to be copied. > > I have the question regarding to the algorithm of GF field calculations > used in the proposed implementation: why not use the recent researches > in GCM calculations, e.g. described in [1], for further speed optimizations? > > [1] - https://eprint.iacr.org/2013/157.pdf The paper you linked to does not describe a new way of calculating GHASH, but evalutation of a bug in their implementation using the PCLMULQDQ instruction... If you mean, why don't I use OpenSSL's code? The reason is that their code is a perl script that generates assmebly... We don't have perl in base.. and I didn't want more assembly in our tree (see below).. Instead, I decided to use code from Intel's whitepaper: Intel® Carry-Less Multiplication Instruction and its Usage for Computing the GCM Mode I didn't use their assembly version because I wanted to have maintainable code, and also the same code can be used on both i386 and amd64 arches.. This turns out to also be a good thing, as when I add segmented buffer support, it'll be much easier to add to the C version, and I only have to do the work once for two arches... Also, the software GF library that I wrote is using state of the art algorithms... An OpenBSD developer has tested my code and has seen a significant performance improvement over their old code, and are evaluating if they want to/can include it in their tree... Hope this answers your question. If not, please be more specific so I can answer it. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-security@FreeBSD.ORG Sat Nov 8 18:55:30 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C964785F; Sat, 8 Nov 2014 18:55:30 +0000 (UTC) Received: from mail.highsecure.ru (mail6.highsecure.ru [IPv6:2a01:4f8:190:43b5::99]) (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 58F7AF0D; Sat, 8 Nov 2014 18:55:30 +0000 (UTC) Received: from medway.cl.cam.ac.uk (medway.cl.cam.ac.uk [IPv6:2001:630:212:238:21c:c0ff:fe4b:2b85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: vsevolod@highsecure.ru) by mail.highsecure.ru (Postfix) with ESMTPSA id 719B43001ED; Sat, 8 Nov 2014 19:55:15 +0100 (CET) Message-ID: <545E6712.5060305@highsecure.ru> Date: Sat, 08 Nov 2014 18:55:14 +0000 From: Vsevolod Stakhov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-security@FreeBSD.org, current@FreeBSD.org Subject: Re: CFR: AES-GCM and OpenCrypto work review References: <20141108042300.GA24601@funkthat.com> In-Reply-To: <20141108042300.GA24601@funkthat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=highsecure.ru; s=dkim; t=1415472915; bh=Q5VdJ/jKR2LsqdtIiMM92ZL8zdtHvh6BtgNimwmlYaA=; h=Message-ID:Date:From:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=G0dYz+F5lY5zSG+TxEvRL1SJtgto/vvphds64DGp/dqDNw4ygnDwJFck2mB2RQkKHrG3es/hBW53w9Z5EsV3d8XueFR9s0HZxZh08rSbo2WQNz1yajUuNIgLOEWBj0RF59ZyzdZn3fRC+F2iQwLn1srHAuxgs2CNFqsPRw+IVUI= X-Mailman-Approved-At: Sat, 08 Nov 2014 20:56:05 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 18:55:31 -0000 On 08/11/14 04:23, John-Mark Gurney wrote: > Hello, > > Over the last few months, I've been working on a project to add support > for AES-GCM and AES-CTR modes to our OpenCrypto framework. The work is > sponsored by The FreeBSD Foundation and Netgate. > > I plan on committing these patches early next week. If you need more > time for review, please email me privately and I will make delay. > > The code has already been reviewed by Watson Ladd (the software crypto > implementations) and Trevor Perrin (the aesni module part) and I have > integrated these changes into the patch. > > There are two patches, one is the changes for OpenCrypto and the test > framework. The other is the data files used by the test framework. > The data is from NIST's CAVP program, and is about 20MB worth of test > vectors. (I just realized, should we look at compressing these on > disk?) > > Main patch (192KB): > https://www.funkthat.com/~jmg/patches/aes.ipsec.5.patch > > Data files (~20MB): > https://www.funkthat.com/~jmg/patches/aes.ipsec.5.testing.patch > > A list of notable changes in the patch: > - Replacing crypto(4) w/ NetBSD's version + updates > - Lots of man page updates, including CIOCFINDDEV and crypto(7) which > adds specifics about restrictions on the modes. > - Allow sane useage of both _HARDWARE and _SOFTWARE flags. > - Add a timing safe bcmp for MAC comparision. > - Add a software implementation of GCM that uses a four bit lookup > table with parallelization. This algorithm is possibly vulnerable to > timing attacks, but best known mitigation methods are used. Using > a timing safe version is many times slower. > - Added a CRYPTDEB macro that defaults to off. > - Bring in some of OpenBSD's improvements to the OpenCrypto framework. > - If an mbuf passed to the aesni module is only one segment, don't do > a copy. This needs to be improved to support segmented buffers. > - Remove the CRYPTO_F_REL flag. It was meaningless. It was used but > did not change any behavior. > - Add function crypto_mbuftoiov to convert an mbuf to an iov. This > also converts the software crypto to only use iov's even for a simple > linear buffer, and so simplifies the processing. > - Add a dtrace probe for errors from the ioctl. > - Add the CIOCCRYPTAEAD ioctl that allows userland processing (testing) > of AES-GCM and future AEAD modes. > > Future improvements: > - Support IV's longer than 12 bytes for GCM. > - Make AES-NI support segmented buffers (iov or mbuf) so multisegmented > inputs don't have to be copied. I have the question regarding to the algorithm of GF field calculations used in the proposed implementation: why not use the recent researches in GCM calculations, e.g. described in [1], for further speed optimizations? [1] - https://eprint.iacr.org/2013/157.pdf -- Vsevolod Stakhov From owner-freebsd-security@FreeBSD.ORG Sat Nov 8 21:20:11 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74348763; Sat, 8 Nov 2014 21:20:11 +0000 (UTC) Received: from mail.highsecure.ru (mail6.highsecure.ru [IPv6:2a01:4f8:190:43b5::99]) (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 1EE65D81; Sat, 8 Nov 2014 21:20:10 +0000 (UTC) Received: from [172.24.168.60] (global-2-11.nat.csx.cam.ac.uk [131.111.185.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: vsevolod@highsecure.ru) by mail.highsecure.ru (Postfix) with ESMTPSA id 105C8300092; Sat, 8 Nov 2014 22:20:05 +0100 (CET) Message-ID: <545E8904.6070109@highsecure.ru> Date: Sat, 08 Nov 2014 21:20:04 +0000 From: Vsevolod Stakhov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: John-Mark Gurney Subject: Re: CFR: AES-GCM and OpenCrypto work review References: <20141108042300.GA24601@funkthat.com> <545E6712.5060305@highsecure.ru> <20141108204538.GI24601@funkthat.com> In-Reply-To: <20141108204538.GI24601@funkthat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=highsecure.ru; s=dkim; t=1415481605; bh=w+WG2PRWGmMIwDUKlJKdj1bM+jfhG0lstSX1N/dogQE=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=MEbXCq1hR2T/av7jaetwUSgAZMREybYOBnJ4TyxmNnKpYpGBKxJpf9KznDb30h1TAalaOEEV32ywRW+A0zXylCKALabG2Lp69Y3tPD8bIkBQpttMYziFL28lhyc2W1jyUIafaFJFg+pu/TD3SvbwxpyDiljc3OZ7jt3XfU2aYBk= X-Mailman-Approved-At: Sat, 08 Nov 2014 22:58:37 +0000 Cc: freebsd-security@freebsd.org, FreeBSD-Current X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 21:20:11 -0000 On 08/11/14 20:45, John-Mark Gurney wrote: > Vsevolod Stakhov wrote this message on Sat, Nov 08, 2014 at 18:55 +0000: >> On 08/11/14 04:23, John-Mark Gurney wrote: >>> Hello, >>> >>> Over the last few months, I've been working on a project to add support >>> for AES-GCM and AES-CTR modes to our OpenCrypto framework. The work is >>> sponsored by The FreeBSD Foundation and Netgate. >>> >>> I plan on committing these patches early next week. If you need more >>> time for review, please email me privately and I will make delay. >>> >>> The code has already been reviewed by Watson Ladd (the software crypto >>> implementations) and Trevor Perrin (the aesni module part) and I have >>> integrated these changes into the patch. >>> >>> There are two patches, one is the changes for OpenCrypto and the test >>> framework. The other is the data files used by the test framework. >>> The data is from NIST's CAVP program, and is about 20MB worth of test >>> vectors. (I just realized, should we look at compressing these on >>> disk?) >>> >>> Main patch (192KB): >>> https://www.funkthat.com/~jmg/patches/aes.ipsec.5.patch >>> >>> Data files (~20MB): >>> https://www.funkthat.com/~jmg/patches/aes.ipsec.5.testing.patch >>> >>> A list of notable changes in the patch: >>> - Replacing crypto(4) w/ NetBSD's version + updates >>> - Lots of man page updates, including CIOCFINDDEV and crypto(7) which >>> adds specifics about restrictions on the modes. >>> - Allow sane useage of both _HARDWARE and _SOFTWARE flags. >>> - Add a timing safe bcmp for MAC comparision. >>> - Add a software implementation of GCM that uses a four bit lookup >>> table with parallelization. This algorithm is possibly vulnerable to >>> timing attacks, but best known mitigation methods are used. Using >>> a timing safe version is many times slower. >>> - Added a CRYPTDEB macro that defaults to off. >>> - Bring in some of OpenBSD's improvements to the OpenCrypto framework. >>> - If an mbuf passed to the aesni module is only one segment, don't do >>> a copy. This needs to be improved to support segmented buffers. >>> - Remove the CRYPTO_F_REL flag. It was meaningless. It was used but >>> did not change any behavior. >>> - Add function crypto_mbuftoiov to convert an mbuf to an iov. This >>> also converts the software crypto to only use iov's even for a simple >>> linear buffer, and so simplifies the processing. >>> - Add a dtrace probe for errors from the ioctl. >>> - Add the CIOCCRYPTAEAD ioctl that allows userland processing (testing) >>> of AES-GCM and future AEAD modes. >>> >>> Future improvements: >>> - Support IV's longer than 12 bytes for GCM. >>> - Make AES-NI support segmented buffers (iov or mbuf) so multisegmented >>> inputs don't have to be copied. >> >> I have the question regarding to the algorithm of GF field calculations >> used in the proposed implementation: why not use the recent researches >> in GCM calculations, e.g. described in [1], for further speed optimizations? >> >> [1] - https://eprint.iacr.org/2013/157.pdf > > The paper you linked to does not describe a new way of calculating > GHASH, but evalutation of a bug in their implementation using the > PCLMULQDQ instruction... > > If you mean, why don't I use OpenSSL's code? The reason is that their > code is a perl script that generates assmebly... We don't have > perl in base.. and I didn't want more assembly in our tree (see below).. > > Instead, I decided to use code from Intel's whitepaper: > Intel® Carry-Less Multiplication Instruction and its Usage for > Computing the GCM Mode > > I didn't use their assembly version because I wanted to have > maintainable code, and also the same code can be used on both i386 > and amd64 arches.. This turns out to also be a good thing, as when > I add segmented buffer support, it'll be much easier to add to the C > version, and I only have to do the work once for two arches... > > Also, the software GF library that I wrote is using state of the art > algorithms... An OpenBSD developer has tested my code and has seen > a significant performance improvement over their old code, and are > evaluating if they want to/can include it in their tree... > > Hope this answers your question. If not, please be more specific so > I can answer it. > > Thanks. > I'm sorry, I thought that is the paper that is a transcript of the following presentation: http://2013.diac.cr.yp.to/slides/gueron.pdf made by the same authors. The transcript is not available so far it seems. And regarding assembler/C maintainability I would argue that the current intrinsics based implementation is more readable than the pure assembler solution (and it is still machine dependent). Of course, I'm not the expert in such optimizations, so that is just my own feeling. By the way, do you have some concrete numbers about the performance of your aes-gcm? (I recently could do aes-128-gcm at about 32 gigabits/sec that is not a limit of the modern hardware for sure).