Date: Tue, 28 Jul 2015 23:50:51 -0600 From: Roger Wilson <roger@softridge.com> To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-15:15.tcp Message-ID: <55B869BB.5070304@softridge.com> In-Reply-To: <20150728203026.4D19C1754@freefall.freebsd.org> References: <20150728203026.4D19C1754@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Probably not an issue; but would not hurt to patch anyway if it can be done as part of other patches. Roger Ben Wilson 303-579-5521, cell roger@softridge.com On 07/28/2015 14:30 , FreeBSD Security Advisories wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > ============================================================================= > FreeBSD-SA-15:15.tcp Security Advisory > The FreeBSD Project > > Topic: Resource exhaustion in TCP reassembly > > Category: core > Module: inet > Announced: 2015-07-28 > Credits: Patrick Kelsey (Norse Corporation) > Affects: All supported versions of FreeBSD. > Corrected: 2015-07-28 19:58:44 UTC (stable/10, 10.2-PRERELEASE) > 2015-07-28 19:58:44 UTC (stable/10, 10.2-BETA2-p2) > 2015-07-28 19:59:04 UTC (releng/10.2, 10.2-RC1-p1) > 2015-07-28 19:59:11 UTC (releng/10.1, 10.1-RELEASE-p16) > 2015-07-28 19:58:54 UTC (stable/9, 9.3-STABLE) > 2015-07-28 19:59:22 UTC (releng/9.3, 9.3-RELEASE-p21) > 2015-07-28 19:58:54 UTC (stable/8, 8.4-STABLE) > 2015-07-28 19:59:22 UTC (releng/8.4, 8.4-RELEASE-p35) > CVE Name: CVE-2015-1417 > > For general information regarding FreeBSD Security Advisories, > including descriptions of the fields above, security branches, and the > following sections, please visit <URL:https://security.FreeBSD.org/>. > > I. Background > > The Transmission Control Protocol (TCP) of the TCP/IP protocol suite > provides a connection-oriented, reliable, sequence-preserving data > stream service. > > The underlying simple and potentially unreliable IP datagram > communication protocol may deliver segments out of order, therefore, > the TCP receiver would need to reassemble the segments into their > original sequence to provide a reliable octet stream. Because the > reassembly requires additional resources to keep the queued segments, > historically resource exhaustion in the TCP reassembly path has been > prevented by limiting the total number of segments that could belong > to reassembly queues to a small fraction (1/16) of the total number of > mbuf clusters in the system. > > VNET is a technique to virtualize the network stack, first introduced in > FreeBSD 8.0. It changes global resources in the network stack into per > network stack resources, so that a virtual network stack can be attached > to a jailed prison and the prison can have unrestricted access to the > virtual network stack. VNET is not enabled by default and has to be > enabled by recompiling the kernel. > > II. Problem Description > > There is a mistake with the introduction of VNET, which converted the > global limit on the number of segments that could belong to reassembly > queues into a per-VNET limit. Because mbufs are allocated from a > global pool, in the presence of a sufficient number of VNETs, the > total number of mbufs attached to reassembly queues can grow to the > total number of mbufs in the system, at which point all network > traffic would cease. > > III. Impact > > An attacker who can establish concurrent TCP connections across a > sufficient number of VNETs and manipulate the inbound packet streams > such that the maximum number of mbufs are enqueued on each reassembly > queue can cause mbuf cluster exhaustion on the target system, resulting > in a Denial of Service condition. > > As the default per-VNET limit on the number of segments that can > belong to reassembly queues is 1/16 of the total number of mbuf > clusters in the system, only systems that have 16 or more VNET > instances are vulnerable. > > IV. Workaround > > FreeBSD 8.x, 9.x and 10.x systems that do not make use of VNETs > (option VIMAGE) are not affected. The support has to be specifically > compiled into a custom kernel, so its use is not common. > > For affected systems, the system administrators may consider reducing > the net.inet.tcp.reass.maxsegments tunable to the value of > kern.ipc.nmbclusters divided by one greater than the total number of > VNETs that are going to be used in the system in order to prevent a > Denial of Service via this vulnerability. For example, if there are > 16 VNETs in the system, the net.inet.tcp.reass.maxsegments tunable > should be set to kern.ipc.nmbclusters / 17. > > 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, > and reboot the system. > > 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 > > And reboot the system. > > 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 10.2] > # fetch https://security.FreeBSD.org/patches/SA-15:15/tcp.patch > # fetch https://security.FreeBSD.org/patches/SA-15:15/tcp.patch.asc > # gpg --verify tcp.patch.asc > > [FreeBSD 9.3 and 10.1] > # fetch https://security.FreeBSD.org/patches/SA-15:15/tcp-9.3-10.1.patch > # fetch https://security.FreeBSD.org/patches/SA-15:15/tcp-9.3-10.1.patch.asc > # gpg --verify tcp-9.3-10.1.patch.asc > > [FreeBSD 8.4] > # fetch https://security.FreeBSD.org/patches/SA-15:15/tcp-8.patch > # fetch https://security.FreeBSD.org/patches/SA-15:15/tcp-8.patch.asc > # gpg --verify tcp-8.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 > <URL:https://www.FreeBSD.org/handbook/kernelconfig.html>; and reboot the > system. > > VI. Correction details > > The following list contains the correction revision numbers for each > affected branch. > > Branch/path Revision > - ------------------------------------------------------------------------- > stable/8/ r285977 > releng/8.4/ r285980 > stable/9/ r285977 > releng/9.3/ r285980 > stable/10/ r285976 > releng/10.1/ r285979 > releng/10.2/ r285978 > - ------------------------------------------------------------------------- > > 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: > > <URL:https://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>; > > VII. References > > <URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1417>; > > The latest revision of this advisory is available at > <URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-15:15.tcp.asc>; > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.1.6 (FreeBSD) > > iQIcBAEBCgAGBQJVt+FcAAoJEO1n7NZdz2rnOAgQAKw0jR1Eb/USmcXlFpfMrmUr > Z6UWHsPqE9CwDJaFddrFBRyjCsbeBv4LmPyVcOKJoqspEb8P52GtBNDe9vqcco1U > C+KpcQQKWTQmu170AdLAIRVvLjoNEX0C09ig4XMbKpisrmQ8zLXavTbTw8FlbPXq > o9t0nFgPKsDfaXJF3Oas41K/NsBj4hdqnfx+R7KeOaJ6sSwiFGbRxqQ+GG3k+79a > RI+KVLpw4QV/IkhXKzl416o6uk7eWnJu72GohdrxPvXYWHBVSBkSiT7pLl3O5C7r > 7+dpYyF9f4K0gnXLuATNixNS2/lL2WaJANb75ku7WnY2I5Yjx1oM2r5kE2eJ6Z/c > WXGnDE9/8SOVURqMwnpQgzVGopKZags0+X7FJAYKeW4/nWyUEAmDlQ+9dY7o/I0M > urFD+bsSxnrlGLLzjX55zKM1qyGlhNokowSusVeNlSEOl8/QV57CuyQDZ0wdAiUd > R2yl+fFxRKn4AeCMuKkEsoExLhISI7Uuz8Hjia7g0yJWfYjEjAWLcFpan/QmhwcP > 4PMg+2ZuPC0uUoXqCMBqu3d0NAaae4cOCzx8WCZUaaF3DwhRnUcld+XesV/h3SNo > kn3ygFyOVWrCd7bSsEd00qqUwUN/cp/uYTqlbI9im89Emaa7/mYR/i3sq2/MRagr > 2oio8OdZ8wwRuER4Jpq9 > =PC1V > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-security-notifications@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications > To unsubscribe, send any mail to "freebsd-security-notifications-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55B869BB.5070304>