what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

FreeBSD Security Advisory - TCP Reassembly Resource Exhaustion

FreeBSD Security Advisory - TCP Reassembly Resource Exhaustion
Posted Jul 28, 2015
Authored by Patrick Kelsey | Site security.freebsd.org

FreeBSD Security Advisory - 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. 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.

tags | advisory, denial of service, tcp
systems | freebsd
advisories | CVE-2015-1417
SHA-256 | 4651dfbd0c91abc16de434dacb94a6bbd086b3657240c2386bbf868ee0921266

FreeBSD Security Advisory - TCP Reassembly Resource Exhaustion

Change Mirror Download
-----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-----
Login or Register to add favorites

File Archive:

September 2022

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Sep 1st
    23 Files
  • 2
    Sep 2nd
    12 Files
  • 3
    Sep 3rd
    0 Files
  • 4
    Sep 4th
    0 Files
  • 5
    Sep 5th
    10 Files
  • 6
    Sep 6th
    8 Files
  • 7
    Sep 7th
    30 Files
  • 8
    Sep 8th
    14 Files
  • 9
    Sep 9th
    26 Files
  • 10
    Sep 10th
    0 Files
  • 11
    Sep 11th
    0 Files
  • 12
    Sep 12th
    5 Files
  • 13
    Sep 13th
    28 Files
  • 14
    Sep 14th
    15 Files
  • 15
    Sep 15th
    17 Files
  • 16
    Sep 16th
    9 Files
  • 17
    Sep 17th
    0 Files
  • 18
    Sep 18th
    0 Files
  • 19
    Sep 19th
    12 Files
  • 20
    Sep 20th
    15 Files
  • 21
    Sep 21st
    20 Files
  • 22
    Sep 22nd
    13 Files
  • 23
    Sep 23rd
    12 Files
  • 24
    Sep 24th
    0 Files
  • 25
    Sep 25th
    0 Files
  • 26
    Sep 26th
    0 Files
  • 27
    Sep 27th
    0 Files
  • 28
    Sep 28th
    0 Files
  • 29
    Sep 29th
    0 Files
  • 30
    Sep 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Hosting By
Rokasec
close