Thomas Steen Rasmussen
2014-May-05 08:57 UTC
FreeBSD-SA-14:08.tcp has nothing to do with tcp fragments!
-----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-----
Kimmo Paasiala
2014-May-07 23:18 UTC
FreeBSD-SA-14:08.tcp has nothing to do with tcp fragments!
On 5.5.2014, at 11.57, Thomas Steen Rasmussen <thomas at gibfest.dk> wrote:> Signed PGP part > 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.ascHello, I?ve been wondering about the same question and done some reading of the PF source code. If we assume that (so we can agree on terminology, repeating what you?re saying above somewhat): - A fragment is a result of IP fragmentation when a packet is too large to fit in to the MTU. - A segment is the unit for re-ordering reassembly for packets that have arrived out of order. The PF source code mostly uses the term ?Fragment? in parts of it that implements the scrub operations and the about the only mention of a ?Segment? is in this comment at line 1888 of sys/netpfil/pf/pf_norm.c. http://svnweb.freebsd.org/base/stable/10/sys/netpfil/pf/pf_norm.c?revision=263086&view=markup&sortby=rev&sortdir=down#l1888 The comment says "/* I have a dream.... TCP segment reassembly.... */?. Unless there?s a mixup in the terminology in PF?s source I would make a bet that PF scrub rules do not perform TCP segment reassembly for packets that have arrived out of order. -Kimmo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20140508/438e3143/attachment.sig>