-----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 . 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 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: VII. References The latest revision of this advisory is available at -----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-----