FreeBSD Security Advisory FreeBSD-SA-15:15.tcp
Roger Wilson
roger at softridge.com
Wed Jul 29 05:51:01 UTC 2015
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 at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications
> To unsubscribe, send any mail to "freebsd-security-notifications-unsubscribe at freebsd.org"
More information about the freebsd-security
mailing list