From owner-freebsd-security@freebsd.org Wed Jul 29 05:51:01 2015 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A43D9AE3F8 for ; Wed, 29 Jul 2015 05:51:01 +0000 (UTC) (envelope-from roger@softridge.com) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A14B6B7 for ; Wed, 29 Jul 2015 05:51:00 +0000 (UTC) (envelope-from roger@softridge.com) Received: by iggf3 with SMTP id f3so5881769igg.1 for ; Tue, 28 Jul 2015 22:50:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kMR3pjLUSbyBqYsDqeYsL5U3FuT8/kYo7GnVtywcpe0=; b=ExqZQIE5Nd2phhIuzIeq3vJ/0tuddKkaEUJz7kSVuDJKApUzbRsj+EBdPqqT1Hqi35 e3mla0jZI4IZx8EmvvN2fwfWvsiwA30i3Il3UklxNm9wg6+NURc1FSiJ5ou+pWxHra63 Q8eZnR2m/HyBxFN5dTgwUbX2MmEnTOWWdmgJ9/5cv4mklowoPtShLI0ORa4jN+vbPzwk MC0e0Q84VZNB4KEr0ceQlh0P8FpWQFQodWIfwIhEp1gkKszUgIAWv0dwwbFla2eN2a4c TyY1q2h0jctiwNd0p42dcTX5YEmmfw06z+A77IELHSYXK1/UyO1zP1jNYgWQ5Lh7JkZO l04Q== X-Gm-Message-State: ALoCoQkbIG88RN5jJKQfs4UUz6AglDaMVDQVL0a+syxGcJzxuzhcZelvN7BNSRKDv7RgTyENosKD X-Received: by 10.50.61.234 with SMTP id t10mr2369742igr.19.1438149053820; Tue, 28 Jul 2015 22:50:53 -0700 (PDT) Received: from earth.local (c-73-153-237-205.hsd1.co.comcast.net. [73.153.237.205]) by smtp.googlemail.com with ESMTPSA id c20sm15288605ioe.36.2015.07.28.22.50.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2015 22:50:52 -0700 (PDT) Message-ID: <55B869BB.5070304@softridge.com> Date: Tue, 28 Jul 2015 23:50:51 -0600 From: Roger Wilson User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-15:15.tcp References: <20150728203026.4D19C1754@freefall.freebsd.org> In-Reply-To: <20150728203026.4D19C1754@freefall.freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 29 Jul 2015 11:24:46 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 05:51:01 -0000 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@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 . > > 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----- > _______________________________________________ > freebsd-security-notifications@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications > To unsubscribe, send any mail to "freebsd-security-notifications-unsubscribe@freebsd.org"