From owner-freebsd-security@freebsd.org Wed Jul 22 13:19:05 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 D71749A699D for ; Wed, 22 Jul 2015 13:19:05 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 932091BB2; Wed, 22 Jul 2015 13:19:05 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1ZHtvF-000JNl-14; Wed, 22 Jul 2015 16:18:57 +0300 Date: Wed, 22 Jul 2015 16:18:56 +0300 From: Slawa Olhovchenkov To: freebsd-security@freebsd.org Cc: FreeBSD Security Advisories Subject: Re: FreeBSD Security Advisory FreeBSD-SA-15:13.tcp Message-ID: <20150722131856.GD43740@zxy.spb.ru> References: <20150722025746.721831C32@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150722025746.721831C32@freefall.freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 22 Jul 2015 13:19:05 -0000 On Wed, Jul 22, 2015 at 02:57:46AM +0000, FreeBSD Security Advisories wrote: This is correspondent to kern/25986? Or kern/25986 is different bug? > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > ============================================================================= > FreeBSD-SA-15:13.tcp Security Advisory > The FreeBSD Project > > Topic: Resource exhaustion due to sessions stuck in LAST_ACK state > > Category: core > Module: inet > Announced: 2015-07-21 > Credits: Lawrence Stewart (Netflix, Inc.), > Jonathan Looney (Juniper SIRT) > Affects: All supported versions of FreeBSD. > Corrected: 2015-07-21 23:42:17 UTC (stable/10, 10.2-PRERELEASE) > 2015-07-21 23:42:17 UTC (stable/10, 10.2-BETA1-p1) > 2015-07-21 23:42:17 UTC (stable/10, 10.2-BETA2-p1) > 2015-07-21 23:42:56 UTC (releng/10.1, 10.1-RELEASE-p15) > 2015-07-21 23:42:20 UTC (stable/9, 9.3-STABLE) > 2015-07-21 23:42:56 UTC (releng/9.3, 9.3-RELEASE-p20) > 2015-07-21 23:42:20 UTC (stable/8, 8.4-STABLE) > 2015-07-21 23:42:56 UTC (releng/8.4, 8.4-RELEASE-p34) > CVE Name: CVE-2015-5358 > > 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. > > A socket enters the LAST_ACK state when the local process closes its socket > after a FIN has already been received from the remote peer. The socket > will remain in the LAST_ACK state until the kernel has transmitted a FIN to > the remote peer and the kernel has received an acknowledgement of that FIN > from the remote peer, or all retransmits of the FIN have failed and the > connection times out. > > II. Problem Description > > TCP connections transitioning to the LAST_ACK state can become permanently > stuck due to mishandling of protocol state in certain situations, which in > turn can lead to accumulated consumption and eventual exhaustion of system > resources, such as mbufs and sockets. > > III. Impact > > An attacker who can repeatedly establish TCP connections to a victim system > (for instance, a Web server) could create many TCP connections that are > stuck in LAST_ACK state and cause resource exhaustion, resulting in a > denial of service condition. This may also happen in normal operation > where no intentional attack is conducted, but an attacker who can send > specifically crafted packets can trigger this more reliably. > > IV. Workaround > > No workaround is available, but systems that do not provide TCP based > service to untrusted networks are not vulnerable. > > Note that the tcpdrop(8) utility can be used to purge connections which > have become wedged. For example, the following command can be used to > generate commands that would drop all connections whose last rcvtime is > more than 100s: > > netstat -nxp tcp | \ > awk '{ if (int($NF) > 100) print "tcpdrop " $4 " " $5 }' > > The system administrator can then run the generated script as a temporary > measure. Please refer to the tcpdump(8) manual page for additional > information. > > 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. > > 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 > > 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.1] > # fetch https://security.FreeBSD.org/patches/SA-15:13/tcp.patch > # fetch https://security.FreeBSD.org/patches/SA-15:13/tcp.patch.asc > # gpg --verify tcp.patch.asc > > [FreeBSD 9.x and 8.x] > # fetch https://security.FreeBSD.org/patches/SA-15:13/tcp-9.patch > # fetch https://security.FreeBSD.org/patches/SA-15:13/tcp-9.patch.asc > # gpg --verify tcp-9.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/ r285779 > releng/8.4/ r285780 > stable/9/ r285779 > releng/9.3/ r285780 > stable/10/ r285778 > releng/10.1/ r285780 > - ------------------------------------------------------------------------- > > 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) > > iQIcBAEBCgAGBQJVrtnrAAoJEO1n7NZdz2rnchoQAMUV9fuXsBvQgvugFVpoe4HP > t7tTIzKKmvC3SVOQfPF6jQllVL9qbRJK9zVdFcGX0Iy07/QPKMIRIFXqiYmRwyXt > YEuZtZMHEo6w5YS/gEwSndGRFduFAfhaNZndycjA3O5nxR16cvqScDUAv0nErQGD > jJzhjbwdrT4fLg06PgLOdNwQKOPhdM1k4ZOdg7WUYDi2iQUmYpD2SOzRAx/SoDK7 > N0qd7Cy7mZBLbmm1zbCGDPhvNVYCKQjPjhiZ1GhfzUQ2n9bBOGLf2K1d/N0cttFH > /MfJoi2yRlU3iJE2DOJeD0/m4sJLmTL/7sqYEP9W2939oVH0Bku/KoJG4I4rZLDl > 6yoKTxtyJGxbw8N2M/ObFpCQwn56Vjf2oo1LhIdBb+T48OwSwxuwrtw4VnlUnVLo > oJ5UA1VnazoyU6AwADpHkGPEPvRF1SUXfOuIOoHiZZ6O3eHdoeD3e2HqLQhoYVCj > PMEi/k45jPnWWhwV76I65Ig02YRgzhMTSunjXLQhi44Eeavf1SxHTJpSHuVjg3zu > MDDW55yB+wJvoetwCg3IkFPfmFBmto679xywDCKVd9VYeKoFsiVE4F/APqf6hN7o > qO8etL5oXnwjNsm9Tf8vImoWrBw2gRYkSieG+Vsx4r2r5JNHKRg1AVmRdihI1ATb > canMZYhLMD6A1x5T54Ya > =UPeI > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"