-----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-----