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.
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/
# fetch https://security.FreeBSD.org/
# gpg --verify tcp.patch.asc
[FreeBSD 9.3 and 10.1]
# fetch https://security.FreeBSD.org/
# fetch https://security.FreeBSD.org/
# gpg --verify tcp-9.3-10.1.patch.asc
[FreeBSD 8.4]
# fetch https://security.FreeBSD.org/
# fetch https://security.FreeBSD.org/
# 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/
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.
VII. References
<URL:https://cve.mitre.org/
The latest revision of this advisory is available at
<URL:https://security.FreeBSD.
Komentarų nėra:
Rašyti komentarą