On 5.5.2014, at 11.57, Thomas Steen Rasmussen <tho...@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.asc Hello, 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
