From owner-freebsd-security@freebsd.org Tue May 12 19:44:27 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 E4A332F8F21 for ; Tue, 12 May 2020 19:44:27 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49M7Y74wZBz3DvJ; Tue, 12 May 2020 19:44:27 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 945) id 69179361B; Tue, 12 May 2020 19:44:27 +0000 (UTC) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-20:12.libalias Reply-To: freebsd-security@freebsd.org Precedence: bulk Message-Id: <20200512194427.69179361B@freefall.freebsd.org> Date: Tue, 12 May 2020 19:44:27 +0000 (UTC) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.33 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 19:44:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-20:12.libalias Security Advisory The FreeBSD Project Topic: Insufficient packet length validation in libalias Category: core Module: libalias Announced: 2020-05-12 Credits: Lucas Leong (@_wmliang_) of Trend Micro Zero Day Initiative Vishnu working with Trend Micro Zero Day Initiative Affects: All supported versions of FreeBSD. Corrected: 2020-05-12 16:49:04 UTC (stable/12, 12.1-STABLE) 2020-05-12 16:51:11 UTC (releng/12.1, 12.1-RELEASE-p5) 2020-05-12 16:49:04 UTC (stable/11, 11.4-STABLE) 2020-05-12 16:51:11 UTC (releng/11.4, 11.4-BETA1-p1) 2020-05-12 16:51:11 UTC (releng/11.3, 11.3-RELEASE-p9) CVE Name: CVE-2020-7454 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The ipfw(4) system facility allows IP packet filtering, redirecting, and traffic accounting. The ipfw(4) packet filter also contains two different methods of accomplishing network address translation (NAT): in-kernel and userspace. Both implementations use the same functions provided by libalias. The libalias(3) library is a collection of functions for aliasing and dealiasing of IP packets, intended for masquerading and NAT. Additionally, libalias(3) includes modules to support protocols that require additional logic to support address translation. Note: libalias(3) is not used by either the pf(4) or ipf(4) firewalls. II. Problem Description libalias(3) packet handlers do not properly validate the packet length before accessing the protocol headers. As a result, if a libalias(3) module does not properly validate the packet length before accessing the protocol header, it is possible for an out of bound read or write condition to occur. III. Impact A malicious attacker could send specially constructed packets that exploit the lack of validation allowing the attacker to read or write memory either from the kernel (for the in-kernel NAT implementation) or from the process space for natd (for the userspace implementation). IV. Workaround No workaround is available. Only systems using NAT and ipfw together are affected. Systems using ipfw(4) without NAT, or systems leveraging pf(4) or ipf(4) are not affected. V. Solution 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 i386 or amd64 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-20:12/libalias.patch # fetch https://security.FreeBSD.org/patches/SA-20:12/libalias.patch.asc # gpg --verify libalias.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/12/ r360971 releng/12.1/ r360972 stable/11/ r360971 releng/11.4/ r360972 releng/11.3/ r360972 - ------------------------------------------------------------------------- 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----- iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl663tdfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n 5cK1Iw/7BpU400GeYsWt6xd+tUuBqGGB6a28+4G/e2GkqMF83vwAaf9+M4siM4Md t0RUDLhcC3irLtGehLcXmVdWZUakmacGa3pGza3E8qdCSQC6+VdO4ghzk5fRlVf0 jmcvCi7zml0YhmATkfMBscPeOJmvENUpouVIwzn4CXMwCKMofjKXdW8+tiT6ppsD RVVeUrGdslVo40KZ8wqxx4y2IMKZ7qW/UZnqWQFAAD3d3iQBJXORpy1xn0AZStY2 ddnhkKdBOyKs5JLoJfSwP8vyTi4iMXPFILP1spuTAqxEFBRTZ3rTE81jimznhp5N /OXI92khj6deiTc1kun+ef3n89e1w6KO4Dt1LUNL08N4mpEwLwvBGLS/5v/3KVpm Q6XknASLY4RaWdj1D5zbPY6F+JFUv22la5mdia4Gn1zxjsyZNMGgM6nx8OCZn4qg JTr7RT4f+EubkEwYD1sw60iTYsqM3o1gFUzkFdEAotWU4tl3nxRkUwusikX7Uu7e 2QY46Sg/6NxW+oelx1qDGjMlP2CIlEsEqj4ND3eJzJT6nef1xmmTUUu+kQF4TBtX J7XqmuTzST2ySPhBUEIOKbjmzdbe+zpbraADhq5BS3zKKmcVSqmqJxkXPxzCwIwb uMcg2spQ5fzP/BquOGdQSx0rD3dQ5lTNX6QZyDaKHZR78ZAEiVE= =I9Vz -----END PGP SIGNATURE----- From owner-freebsd-security@freebsd.org Tue May 12 19:44:31 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 7D49D2F8FA1 for ; Tue, 12 May 2020 19:44:31 +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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49M7YC2PB5z3Dx9; Tue, 12 May 2020 19:44:31 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 945) id 2A72735A6; Tue, 12 May 2020 19:44:31 +0000 (UTC) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-20:13.libalias Reply-To: freebsd-security@freebsd.org Precedence: bulk Message-Id: <20200512194431.2A72735A6@freefall.freebsd.org> Date: Tue, 12 May 2020 19:44:31 +0000 (UTC) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.33 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 19:44:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-20:13.libalias Security Advisory The FreeBSD Project Topic: Memory disclosure vulnerability in libalias Category: core Module: libalias Announced: 2020-05-12 Credits: Vishnu Dev TJ working with Trend Micro Zero Day Initiative Affects: All supported versions of FreeBSD Corrected: 2020-05-12 16:52:08 UTC (stable/12, 12.1-STABLE) 2020-05-12 16:54:39 UTC (releng/12.1, 12.1-RELEASE-p5) 2020-05-12 16:52:08 UTC (stable/11, 11.4-STABLE) 2020-05-12 16:54:39 UTC (releng/11.4, 11.4-BETA1-p1) 2020-05-12 16:54:39 UTC (releng/11.3, 11.3-RELEASE-p9) CVE Name: CVE-2020-7455 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The ipfw(4) system facility allows IP packet filtering, redirecting, and traffic accounting. The ipfw(4) packet filter also contains two different methods of accomplishing network address translation (NAT): in-kernel and userspace. Both implementations use the same functions provided by libalias. The libalias(3) library is a collection of functions for aliasing and dealiasing of IP packets, intended for masquerading and NAT. Additionally, libalias(3) includes modules to support protocols that require additional logic to support address translation. Note: libalias(3) is not used by either the pf(4) or ipf(4) firewalls. II. Problem Description The FTP packet handler in libalias incorrectly calculates some packet lengths. This may result in disclosing small amounts of memory from the kernel (for the in-kernel NAT implementation) or from the process space for natd (for the userspace implementation). III. Impact A malicious attacker could send specially constructed packets that exploit the erroneous calculation allowing the attacker to disclose small amount of memory either from the kernel (for the in-kernel NAT implementation) or from the process space for natd (for the userspace implementation). IV. Workaround No workaround is available. Only systems using NAT and ipfw together are affected. Systems using ipfw without NAT, or systems leveraging pf(4) or ipf(4) are not affected. V. Solution 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 i386 or amd64 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-20:13/libalias.patch # fetch https://security.FreeBSD.org/patches/SA-20:13/libalias.patch.asc # gpg --verify libalias.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/12/ r360973 releng/12.1/ r360974 stable/11/ r360973 releng/11.4/ r360974 releng/11.3/ r360974 - ------------------------------------------------------------------------- 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----- iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl663tdfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n 5cK3hhAAlkHMjDluGni1AaDicw5jZuyrdGLEMfgH2OdxcrTQvrBN6ZEkfLsiFvLV KWgUS+rx3GJApz4rZ6DFwsb+DG+kMCwYGevbT5zH5IUwe1HklyMLmjw48z47DVhx 8tpjCKNb4ttqBzb6RMURoJgo+2NAUQOZLnFGLSGOkquqeW9AhA97ZIGv7TyOPC1p rJD/ic1IxTUXniNu4soexsRqVoMqv1nA1DLrN4TTooFVCQTHaBUBxSTFlaAsBXyb 7L5GIEydZ2429spQACnFGW4RDveOGB/6Jbt2yHEuu+ASOrwl9sRSu79PYijcz28v yXjI0zG4A+78qmeCMbGHIySrLjc8XaWgr13Kp4S+40MWQhoGHJ2ZZVdLX010WTvm nbGs9NQ60sytxdJn1QRTleiBIKjJiVqNEADfS4DhXa/0HouN3L8dVR/+jPfLMFmT /7GZjhdbn4u0a1ZlgUZ62oHoo8NLop49KY4LHtHd7VpJZ8OfK0qkCN0DL4Ep+Wrg oZWJL5HGhFOEA4TDYuypJ58yIPsTDVa9MuLMx/SBF30jVZcS1LtbiMXXuZs6clig oOk4ZE0hpSRdA69xgX459kcTjU6XVJRnTPWyepG3sNljktwk8jyfwKHXOUpJONos 0jWu0ngj60djS8qCrxdkMn3t26fk0IhbA4leBEM+wAKmWsARt/M= =woOx -----END PGP SIGNATURE----- From owner-freebsd-security@freebsd.org Tue May 12 19:44:36 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 5713C2F9004 for ; Tue, 12 May 2020 19:44:36 +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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49M7YJ0bW5z3F0g; Tue, 12 May 2020 19:44:35 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 945) id CCADE32F5; Tue, 12 May 2020 19:44:35 +0000 (UTC) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-20:14.sctp Reply-To: freebsd-security@freebsd.org Precedence: bulk Message-Id: <20200512194435.CCADE32F5@freefall.freebsd.org> Date: Tue, 12 May 2020 19:44:35 +0000 (UTC) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.33 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 19:44:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-20:14.sctp Security Advisory The FreeBSD Project Topic: Improper checking in SCTP-AUTH shared key update Category: core Module: kernel Announced: 2020-05-12 Credits: da_cheng_shao@yeah.net Affects: FreeBSD 11.3 Corrected: 2019-09-19 10:01:19 UTC (stable/12, 12.1-STABLE) 2019-09-19 10:06:18 UTC (stable/11, 11.3-STABLE) 2020-05-12 16:55:32 UTC (releng/11.3, 11.3-RELEASE-p9) CVE Name: CVE-2019-15878 Note: The upcoming release of FreeBSD 11.4 was branched after the original commit to the stable branch and already includes the fix for this advisory. Similarly, the 12.1 branch was created shortly after the original commit to the stable branch and already includes the fix. For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The Stream Control Transmission Protocol (SCTP) is a transport protocol supporting the socket API. An SCTP packet consists of an SCTP common header and a number of SCTP chunks. The SCTP extension SCTP-AUTH can be used to authenticate SCTP chunks. It uses shared keys which can be managed via the socket API by the application using an SCTP association. II. Problem Description The SCTP layer does improper checking when an application tries to update a shared key. Therefore an unprivileged local user can trigger a use-after- free situation, for example by specific sequences of updating shared keys and closing the SCTP association. III. Impact Triggering the use-after-free situation may result in unintended kernel behaviour including a kernel panic. IV. Workaround No workaround is available. V. Solution 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 i386 or amd64 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-20:14/sctp.patch # fetch https://security.FreeBSD.org/patches/SA-20:14/sctp.patch.asc # gpg --verify sctp.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/12/ r352509 stable/11/ r352509 releng/11.3/ r360975 - ------------------------------------------------------------------------- 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----- iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl666WdfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n 5cL7Gg/9GUkrcdpj9hxsSNTdjc4hnnyeMYAtkonQiak6BwrQQ5VgYMTbFDL3iw6b 4v4W8p/pANfeh8nk7h5Agfe39vUe3TuxFEuRn5aCOO/XuYfPYybhq74HrKTz61Iy LLmeExi+6nsWSIIJZVf1S2cyEc0qOV0fW1rE7Q9KQRSmbQF3i0HhUhPT0b8l/qJ9 tfVtkG3VYjWYF5HeV5WE1PyC0Y8pbrUNmZjbe7FxMilqMJ857eXcQqugrdqflri1 pJ5n8vHWy6OwNg8GVefb3Ht77dFBPlj2Kt02bjrA/ctLThBWPbtYgR+7S263TOnY tjeil+VkgOeeFcZLynbvGThE8/e/sl/G72JD7VtsEooVg+tfkIh83rJNCVaWxiEO u0+y+CmBpeD4ZZidOlqXr40WzpAtWTtnYCOn9eDJk3mn795B/GHpSPcH7RR57jr9 yU5lt0vCjktJY4in5VgTbikqD1369t0qZfLRPT84f1tC4AMTvpjG+AcGhwJfmFZL xQht9oXMWiW28J/Vt/AH5yFFGqEyJMNPl6zvqXSfgsKiMKka+5/FzeP1nFzlYEwG 6ygMm333Ur28l+eQ24nL1XpD8ydWXLnfF6N+onyIdH4c9rQ73omnvINmMBTJqEHC NOEJpmOdUFlX2ugzEqPxrVbGlH9s1I/+veuz+uYnGc3Q1Rtvl4c= =h/Gp -----END PGP SIGNATURE----- From owner-freebsd-security@freebsd.org Tue May 12 19:44:41 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 2BC872F908B for ; Tue, 12 May 2020 19:44:41 +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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49M7YN6zgDz3F3C; Tue, 12 May 2020 19:44:40 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 945) id 8CA83353A; Tue, 12 May 2020 19:44:40 +0000 (UTC) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-20:15.cryptodev Reply-To: freebsd-security@freebsd.org Precedence: bulk Message-Id: <20200512194440.8CA83353A@freefall.freebsd.org> Date: Tue, 12 May 2020 19:44:40 +0000 (UTC) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.33 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 19:44:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-20:15.cryptodev Security Advisory The FreeBSD Project Topic: Use after free in cryptodev module Category: core Module: cryptodev Announced: 2020-05-12 Credits: Yuval Kanarenstein Affects: All supported versions of FreeBSD. Corrected: 2020-01-20 11:19:55 UTC (stable/12, 12.1-STABLE) 2020-05-12 16:57:47 UTC (releng/12.1, 12.1-RELEASE-p5) 2020-01-20 11:19:55 UTC (stable/11, 11.3-STABLE) 2020-05-12 16:57:47 UTC (releng/11.3, 11.3-RELEASE-p9) CVE Name: CVE-2019-15879 Note: The upcoming release of FreeBSD 11.4 was branched after the original commit to the stable branch and already includes the fix for this advisory. For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The cryptodev module permits userland applications to offload cryptographic requests to device drivers in the kernel. Applications create sessions via file descriptors opened from /dev/crypto. II. Problem Description A race condition permitted a data structure in the kernel to be used after it was freed by the cryptodev module. III. Impact An unprivileged process can overwrite arbitrary kernel memory. IV. Workaround Unload the cryptodev kernel module if it is loaded: # kldunload cryptodev Note that the cryptodev module is not loaded by default and is not used by most applications. Specificially, use of accelerated software cryptography, such as AES-NI, in userland applications via libraries such as OpenSSL do not make use of the cryptodev module. V. Solution Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date, and reboot the system. Perform one of the following: 1) 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 # 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. [FreeBSD 12.1] # fetch https://security.FreeBSD.org/patches/SA-20:15/cryptodev.12.patch # fetch https://security.FreeBSD.org/patches/SA-20:15/cryptodev.12.patch.asc # gpg --verify cryptodev.12.patch.asc [FreeBSD 11.3] # fetch https://security.FreeBSD.org/patches/SA-20:15/cryptodev.11.patch # fetch https://security.FreeBSD.org/patches/SA-20:15/cryptodev.11.patch.asc # gpg --verify cryptodev.11.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/12/ r356908 releng/12.1/ r360976 stable/11/ r356908 releng/11.3/ r360976 - ------------------------------------------------------------------------- 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----- iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl663tdfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n 5cLW2A//VW8iJqNaBHhMnCrpl+oDTadzGM3gYVxnM+EEQYzru2Ze0z0tShiAkXrQ NryjwBpMA3r1nyWDYaWMgbHjcG+jQdsIvoiA+fSU9hXEUbpxwX9ZKlaSZUBDX48X YScJMewgHCXNpgkTnIckaIyIadOXX+zWhi5T0LN2tS5M5oejTLndAKo9mQm1Ni50 PYiHFkLzO7v4H6K0cKuJRuHF8+kU1IhvOinZuXwZXoGqmPGTVsA0+T27dWhosaWv Yqh3Pbp5oS1y3NbbOadLPhY146pT2Qrb2mQOEiHvsXMFRgjIEQzH1MYXx5gvpa4K CkMwCV/MuNotscVZ00qhVQEGEVlrhgi2IXinzxde5HYCc3mD/KdcYnYz9zOCeIfb 9RfdvKk8uzUITLyz8ZinZBqIHghnSG3M9/cNj2o/97yRfFJazXF/SI41YoV3hcyE Gb1ncYfaAJ4rL9U6xHMw7V+1LSlMrVsIcWxCM2PS4NTwWcZ8K7mEX51ARjx4k7lx IBEsJ+ExSfZHNkS6/DLZiuLEQKFxIOKlRyZQTALnzNaNTp763idW7zA+9k8ceBRH VO7x3EGNqNPhIss+JHOxDUaXTFfJTcd7XGv291unkZwBJuFhJBfH3S+ZCcF38xVK aweHOoJW5V+D9GKygb9oLjOxOupRkFuRrHFQcvj57FYqs9/GDVc= =8E1l -----END PGP SIGNATURE----- From owner-freebsd-security@freebsd.org Tue May 12 19:44:46 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 6026D2F9119 for ; Tue, 12 May 2020 19:44:46 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49M7YV0tQHz3F5s; Tue, 12 May 2020 19:44:46 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 945) id C143C33E6; Tue, 12 May 2020 19:44:45 +0000 (UTC) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-20:16.cryptodev Reply-To: freebsd-security@freebsd.org Precedence: bulk Message-Id: <20200512194445.C143C33E6@freefall.freebsd.org> Date: Tue, 12 May 2020 19:44:45 +0000 (UTC) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.33 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 19:44:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-20:16.cryptodev Security Advisory The FreeBSD Project Topic: Insufficient cryptodev MAC key length check Category: core Module: cryptodev Announced: 2020-05-12 Credits: Yuval Kanarenstein Affects: FreeBSD 12.1 Corrected: 2020-01-20 11:54:00 UTC (stable/12, 12.1-STABLE) 2020-05-12 16:59:09 UTC (releng/12.1, 12.1-RELEASE-p5) CVE Name: CVE-2019-15880 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The cryptodev module permits userland applications to offload cryptographic requests to device drivers in the kernel. Applications create sessions via file descriptors opened from /dev/crypto. II. Problem Description Requests to create cryptography sessions using a MAC did not validate the user-supplied MAC key length. The cryptodev module allocates a buffer whose size is this user-suppled length. III. Impact An unprivileged process can trigger a kernel panic. IV. Workaround Unload the cryptodev kernel module if it is loaded: # kldunload cryptodev Note that the cryptodev module is not loaded by default and is not used by most applications. Specificially, use of accelerated software cryptography (e.g. AES-NI) in userland applications via libraries such as OpenSSL does not make use of the cryptodev module. V. Solution Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date, and reboot the system. Perform one of the following: 1) 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 # 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-20:16/cryptodev.patch # fetch https://security.FreeBSD.org/patches/SA-20:16/cryptodev.patch.asc # gpg --verify cryptodev.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/12/ r356911 releng/12.1/ r360977 - ------------------------------------------------------------------------- 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----- iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl663tdfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n 5cKFbg/+Ou239S9yDp+FTyDlqq4w8p08kh8nHqB6FO6Q6aIxkEgSu/yO9IZsKSnM o05O8iOVOTRR5xSIBN/aW5d4adH81AV6X66NKUZ0bJwAp16v7YIyivY3ySLOB093 oOTy/wlv0jxAYVzOlqMTuVm4dr9dh+9I9kwF94SDY7/maY0pCuUmVCRi2Y5gvCqu LYkDdG0Mq0pka1sGY8aFvG63oMyZ98gkbBNk666SzJnBDq/QDSL0FASCgYDjG1fE R/BciJpucIFi3JPZgSaKi4j56HiN/LaX63A1rdjza3aRh/sLMr7+GHFI3sn474tu xrkRjwnxr7/dghjspHAvsv+8U1oRIGVxeyaQB+Hd4WvNcVzp2McNBJ9c/z7Ugt1r affyXl0JBBkdVa45xDf/weGwwxcmCWxXxv7gDPelf07p3MNjl5G3pPUCUoRA3XE5 Am1v5E0Eui5s/H4ncodY/ECIAHuOfenzdcpK5xCQUMHkgikfiLftNfLWSVOrqEJn Wxl8/ttKWLYYwYDSYrN0kNvQWc6LHsuA1I7Zt7wpRW09wB2OlZ7Hn2nZebTrXjKG P/AeGa+JVCJ2HZzj1+8qxcFHgq8IRINICvq743e2vIQak0KsgqmtvnLavAlv/p3d zPxFJOPAw0bhJj14qLT+cXGC9u3/qrZWWR0b4S7qeMlLG3Cw4fk= =j3X1 -----END PGP SIGNATURE----- From owner-freebsd-security@freebsd.org Tue May 12 20:36:41 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 CF2882DB5F5 for ; Tue, 12 May 2020 20:36:41 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49M8jP54jtz3xH3; Tue, 12 May 2020 20:36:41 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x831.google.com with SMTP id b1so11557753qtt.1; Tue, 12 May 2020 13:36:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=83jt+ztmwCtAirnrtdqfEkqEJ67TRwFjbaiD3UHj4Ik=; b=QpQBgEJTrqwQVCM7jdFu68X00G8lUj/bqp6/kjGqV+iIHN3ES4jD3JgzIX405D8A/B AyLUZYd50fvuBdf+ukB393xWWBQnaR1Npg0bf9tRKdfSZfcjrFcOOLxm4NruknNEcxEK CQTxNO+FxmRSbdhny0AWMMClGtH+IO58L2HWFZgpiLqhlgC1iRTw0PhUqyW0dSOJaqCo 1Z3EK2MmFiig6P5W1+GQYbsDlX+53JvVPYKHlwaVmjhUVtOJEIwgtAlv1kvTEGIMxbBp ASm4FZLohn9LMZWI93Rq93jH4CFArUUpXnyX3IV+kJwHnPe87Z7a+2tD/NB7sRMNpzFA LHgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=83jt+ztmwCtAirnrtdqfEkqEJ67TRwFjbaiD3UHj4Ik=; b=Kxxun+Dbn/oU4qqdNalno6kH9lXdaU6Sg1M0GWpbVxsOCXwFBWDi0d3yJD+TVw5aBc pHRBH5QYPaeBhkGF66Ub1QXoJguSdaP+b4KGRdWYvv0II9Hk6R18rKexfhfYMu4syGp9 OHZphth6VNRoF9F6uI/83LIpyOVPMRIQfagdYJaUmQTJL1+PPxkr7UjqY+1RWvQC1MDn rp2x9BzFcZDfTBDFC+dzjglAErxLrQIDOBuUH3c1zmQIDqQBmP6fdZfhY4mRse3LPCbq FQfD0hWOUfl/1t9tsEXjmjccVqmrf7HM3B75Iw4bW02C9D+wA00Lt9/20TcQFbc5skTI 66pA== X-Gm-Message-State: AGi0PuYKnIjd2yv5cqGkPl3+GZCiIHSDOmkEXuMbr8xeMWgd8I9ARNlm 4XA3NSvJQ+YWz6Zzf9HsjttIXcY7 X-Google-Smtp-Source: APiQypIs4zwXumwHZS6n0hDXIO3zuGXaehkJOctrQlkWXOYvivEdI3fTBj/dXCqW1X3RP8Ez5lLAHA== X-Received: by 2002:ac8:70c:: with SMTP id g12mr23216485qth.71.1589315800299; Tue, 12 May 2020 13:36:40 -0700 (PDT) Received: from raichu (toroon0560w-lp130-15-184-144-87-103.dsl.bell.ca. [184.144.87.103]) by smtp.gmail.com with ESMTPSA id v28sm10483744qtb.49.2020.05.12.13.36.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 May 2020 13:36:39 -0700 (PDT) Sender: Mark Johnston Date: Tue, 12 May 2020 16:36:35 -0400 From: Mark Johnston To: freebsd-security@freebsd.org Cc: FreeBSD Security Advisories Subject: Re: FreeBSD Security Advisory FreeBSD-SA-20:13.libalias Message-ID: <20200512203635.GA22386@raichu> References: <20200512194431.2A72735A6@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200512194431.2A72735A6@freefall.freebsd.org> X-Rspamd-Queue-Id: 49M8jP54jtz3xH3 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 20:36:41 -0000 On Tue, May 12, 2020 at 07:44:31PM +0000, FreeBSD Security Advisories wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > ============================================================================= > FreeBSD-SA-20:13.libalias Security Advisory > The FreeBSD Project > > Topic: Memory disclosure vulnerability in libalias > > Category: core > Module: libalias > Announced: 2020-05-12 > Credits: Vishnu Dev TJ working with Trend Micro Zero Day Initiative > Affects: All supported versions of FreeBSD > Corrected: 2020-05-12 16:52:08 UTC (stable/12, 12.1-STABLE) > 2020-05-12 16:54:39 UTC (releng/12.1, 12.1-RELEASE-p5) > 2020-05-12 16:52:08 UTC (stable/11, 11.4-STABLE) > 2020-05-12 16:54:39 UTC (releng/11.4, 11.4-BETA1-p1) > 2020-05-12 16:54:39 UTC (releng/11.3, 11.3-RELEASE-p9) > CVE Name: CVE-2020-7455 > > For general information regarding FreeBSD Security Advisories, > including descriptions of the fields above, security branches, and the > following sections, please visit . > > I. Background > > The ipfw(4) system facility allows IP packet filtering, redirecting, and > traffic accounting. The ipfw(4) packet filter also contains two different > methods of accomplishing network address translation (NAT): in-kernel and > userspace. Both implementations use the same functions provided by libalias. > > The libalias(3) library is a collection of functions for aliasing and > dealiasing of IP packets, intended for masquerading and NAT. Additionally, > libalias(3) includes modules to support protocols that require additional > logic to support address translation. > > Note: libalias(3) is not used by either the pf(4) or ipf(4) firewalls. > > II. Problem Description > > The FTP packet handler in libalias incorrectly calculates some packet > lengths. This may result in disclosing small amounts of memory from the > kernel (for the in-kernel NAT implementation) or from the process space for > natd (for the userspace implementation). > > III. Impact > > A malicious attacker could send specially constructed packets that exploit the > erroneous calculation allowing the attacker to disclose small amount of memory > either from the kernel (for the in-kernel NAT implementation) or from the > process space for natd (for the userspace implementation). > > IV. Workaround > > No workaround is available. Only systems using NAT and ipfw together are > affected. Systems using ipfw without NAT, or systems leveraging pf(4) or > ipf(4) are not affected. This is not correct. For kernel NAT to be affected, alias_ftp.ko has to be loaded. natd is vulnerable because libalias_ftp.so is loaded by the default /etc/libalias.conf. The workaround in both cases is to make sure that the alias_ftp module is not used. From owner-freebsd-security@freebsd.org Thu May 14 08:00:45 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 E57062E89E4 for ; Thu, 14 May 2020 08:00:45 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49N3rD3rlPz42DY for ; Thu, 14 May 2020 08:00:44 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-qk1-x730.google.com with SMTP id 190so2170610qki.1 for ; Thu, 14 May 2020 01:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=cB3J7ZE78gDd30LUIuT3vAoeMa2g7RCBN6ZnOWUUHJM=; b=b1QkI4cUdScsrEfkQ1nuwPQE12n+1O/j8lDrRQ8RFcIwjm7v1k7UPd4A1AOGAdIIH4 oiUNlx8J72xdxGq+OqyVBAqr4vYQNcGo6FiJ0Xl9SPfETZG154bUQbr8CkuqnaBKeoJU 1OZ67RJLA9vxMX08hcYpkc5gAE2UjW7zSEULv14Z6NzsqCIGf6XFGSzsyEGJB40JqaDs gPwyQ4Z8GP3R49ETg9jri2YYrsf5XLZis3/aH9zqbMWEMK2ons1k3UUZ6mKyZuIcYwgo d27/ls+Tbw9UbAa5BoTKB/9lkQ5MX0xLv5rmPN6029RX7GbSiFeJWl8sQdx+5Xxbg17v hj1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=cB3J7ZE78gDd30LUIuT3vAoeMa2g7RCBN6ZnOWUUHJM=; b=ISu2BSYZ8RV08cVTaL2wK3aadckYjC3s/BM7QK8M+qSx96ddRKbVsT27qazkSGAJb8 bStgeMPKggdxBLPB6IC4RDWC5iAdMa7oldMWGVOyYXfMBqgCgwoSBdIRmxDX4xmxua1g qkSUsWIWvUFWELB5o0yYoSj1fcVLXaKCfvSIGAw8/sx9/bKKRCGSw8Q3CnZVrL9kFAP/ I4Mk92rL9TwjROVpljE3tB1id9gM+YTACE4RH8nn7MCHgn6GBX69LmrcqQ+zxs8yhtcB EZGs0LUqEeBnmSKh0H54Qo52+g8NqqJcQIJPhdtWT1dJrmakiLyXRb7mepY5jyoG8yce KG+w== X-Gm-Message-State: AOAM5335r05sggW0f50F6eevHUSit7uNnqJx6xgeOSHf9oNkPW4EuzOX JSIpAWZeTUTAs+ZFXry6u8s6uuN/BPgEggkzW07Rdg== X-Google-Smtp-Source: ABdhPJwEMog2pfOZUJEyanJk1SdaT0R9oFHeSjVngtQZuLlccdxbg4RijuzoGfz/yl8j+n0ZH2yHdVqcDReE1Q8OWME= X-Received: by 2002:a37:9bcb:: with SMTP id d194mr3596847qke.16.1589443243239; Thu, 14 May 2020 01:00:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Marcin Wojtas Date: Thu, 14 May 2020 10:00:31 +0200 Message-ID: Subject: Re: ASLR/PIE status in FreeBSD HEAD To: Ed Maste Cc: freebsd-security@freebsd.org, Rafal Jaworowski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 49N3rD3rlPz42DY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=semihalf-com.20150623.gappssmtp.com header.s=20150623 header.b=b1QkI4cU; dmarc=none; spf=none (mx1.freebsd.org: domain of mw@semihalf.com has no SPF policy when checking 2607:f8b0:4864:20::730) smtp.mailfrom=mw@semihalf.com X-Spamd-Result: default: False [-4.29 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[semihalf-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; DMARC_NA(0.00)[semihalf.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[semihalf-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[0.3.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-1.99)[ip: (-9.17), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.42), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 08:00:46 -0000 Hi, wt., 5 maj 2020 o 12:03 Marcin Wojtas napisa=C5=82(a): > > pon., 4 maj 2020 o 17:24 Ed Maste napisa=C5=82(a): > > > > On Mon, 20 Apr 2020 at 10:22, Marcin Wojtas wrote: > > > > > > Indeed I thought of kyua and measuring buildworld execution time for > > > stressing the DUT and having the first comparison numbers for the low > > > price. > > > > > > Do you think it is possible to get help here, i.e. is there a FreeBSD > > > devops team, maintaining the Jenkins CI whose spare cycles could be > > > used for this purpose? Or is this a field requiring external help fro= m > > > interested parties? > > > > There aren't a lot of spare cycles to go around, but putting > > automation in place so that tests like this can easily be performed is > > certainly something that's in the Jenkins team's domain. > > Of course the available bandwidth is a limitation, but IMO we should > start with defining the requirements so that eventually it could be > added to the backlog. > > > > > > Yes, making use of something actively maintained would be great. Do > > > you see a need for IO stressing/benchmarking for the discussed cases? > > > > In the fullness of time I think it's important, but my opinion is that > > it's really functional tests that we need, for enabling features in > > -CURRENT; we can work on benchmarking before and after changing a > > default. > > Understood. Since there seem to be no blockers / major objections at > this point, how do you suggest proceed with the topic? How about > having a live discussion with interested parties, so that we can > establish at least a rough plan allowing to achieve the enablement of > this (and possibly other) feature in a foreseeable perspective? > Any thoughts about having a live discussion on the ALSR/PIE enablement topi= c? Best regards, Marcin