FreeBSD Security Advisory FreeBSD-SA-15:13.tcp
Slawa Olhovchenkov
slw at zxy.spb.ru
Wed Jul 22 13:19:05 UTC 2015
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 <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.
>
> 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
> <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/ 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:
>
> <URL:https://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>
>
> VII. References
>
> <URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5358>
>
> The latest revision of this advisory is available at
> <URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-15:13.tcp.asc>
> -----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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"
More information about the freebsd-security
mailing list