Date: Mon, 05 May 2014 10:57:58 +0200 From: Thomas Steen Rasmussen <thomas@gibfest.dk> To: freebsd-security@freebsd.org Subject: FreeBSD-SA-14:08.tcp has nothing to do with tcp fragments! Message-ID: <53675296.7060908@gibfest.dk>
next in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, I've been following the thread on FreeBSD-SA-14:08.tcp [1] and I am concerned that people seem to have entirely misunderstood the issue entirely - or perhaps it is me :) I'll take the liberty of pasting the first two sections of the advisory [2] here, please read them well: - ---------------------------------------------------------------- I. Background The Transmission Control Protocol (TCP) of the TCP/IP protocol suite provides a connection-oriented, reliable, sequence-preserving data stream service. When network packets making up a TCP stream (``TCP segments'') are received out-of-sequence, they are maintained in a reassembly queue by the destination system until they can be re-ordered and re-assembled. II. Problem Description FreeBSD may add a reassemble queue entry on the stack into the segment list when the reassembly queue reaches its limit. The memory from the stack is undefined after the function returns. Subsequent iterations of the reassembly function will attempt to access this entry. - ---------------------------------------------------------------- Now, the talk on this list has been centered around TCP *fragments*, that is, a given TCP packet that was too big for the MTU somewhere along it's path, which has been split into several packets by a router. But the advisory never mentioned TCP fragments - the issue is about the queue in which *out of order TCP segments* are kept until they can be reassembled. This has nothing to do with TCP fragments, and blocking TCP fragments will do nothing to prevent this issue. The reason that pf's excellent "scrub" option fixes this is that it *reorders* out-of-sequence TCP packets before passing them on. If pf receives TCP packets 1, 3 and 2 in that order, it reorders them before passing them on. This means that FreeBSD doesn't have to do it, which works around the issue. To sum up: The only way to fix this issue without patching FreeBSD is to make sure out-of-order TCP segments never reach the box. Blocking TCP *fragments* will accomplish nothing except perhaps break DNSSEC and other things. Please speak up if you believe anything I wrote is incorrect, Best regards, Thomas Steen Rasmussen [1] http://lists.freebsd.org/pipermail/freebsd-security/2014-May/007683.html [2] http://www.freebsd.org/security/advisories/FreeBSD-SA-14:08.tcp.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTZ1KWAAoJEHcv938JcvpY1EsQAIBdRIDxjYbcAj/ZELqMWWBy hyt6Frpkelbc/QI5XY+bZrYaYXaDFmC3E2vGjWHvH0F8pSr/UeE9JASlaqxRAtT+ wQQLTLyqt5iDBy0dc+qqiBrwOU+rfQgruQz0arm5N8sIcwbRttP/NnW4rJGyIDzh OSiuGgqLrL/5ukRXJ0JhlFVZYOIODuheeweCq36+HJXDBewF5dAtxZOhruI3/V0p vh3fMj32Ncpjy03k1NaffSJvkQBYKlTKuOoMdhnpCxsLn5VXiES0tC+vOocivNwC KtNHouevimIo9y31qswEsDnuo79H38I6lcZNUS+NuBZU2+5iTTwclwDV+/3rbZcy Y06IAKfXe66q3H5kXDpUBc2/t+sIzs0Wooot50Nnf0dYZLcDTNE3O3rcsoYocmmR vBA+Il/LMFmBze/6pBabYtcam/LBiQxdVaocuSWybLRvSnYDpEtdqNPY9ycx+6S1 h8d8xl3i6AKAMmsdI5WMea+pFojEyMmpB6Zx5gDytKKycTgvYZau00h5plZSgSN5 uuK0uoboMjrnf4zM9IwEhqZSsdwd2JdRgesCyl/DkpygCQBgWKSZG9aKkgj4st2p mtoQmfTL8iNDVO+VD4UZ7lo4/beNKkPskBKMwN2tpmugdYLpzejf8bmFbDZl1Z8L INttv7qy1Dc27GYTUUEJ =YP2X -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53675296.7060908>