--Apple-Mail=_18821777-BDDD-4687-9667-078ACD830CE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 5.5.2014, at 11.57, Thomas Steen Rasmussen <[email protected]> wrote: > Signed PGP part > Hello all, >=20 > 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 :) >=20 > I'll take the liberty of pasting the first two sections of > the advisory [2] here, please read them well: >=20 > ---------------------------------------------------------------- > I. Background >=20 > 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. >=20 > II. Problem Description >=20 > 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. > ---------------------------------------------------------------- >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Please speak up if you believe anything I wrote is incorrect, >=20 >=20 > Best regards, >=20 > Thomas Steen Rasmussen >=20 > [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=92ve been wondering about the same question and done some reading of = the PF source code.=20 If we assume that (so we can agree on terminology, repeating what you=92re= 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 =93Fragment=94 in parts of it = that implements the scrub operations and the about the only mention of a = =93Segment=94 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= =3D263086&view=3Dmarkup&sortby=3Drev&sortdir=3Ddown#l1888 The comment says "/* I have a dream.... TCP segment reassembly.... */=93.= =20 Unless there=92s a mixup in the terminology in PF=92s 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 --Apple-Mail=_18821777-BDDD-4687-9667-078ACD830CE0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTar9MAAoJEFvLZC0FWRVpuE0H/29772pBlkWxv+n/Ggl6hPc0 21QBb5Oh96cJRRBOaGwotjqi8RkIdmop74+WVZXAXr1H02oPOW1HJhmu+WbzK9O+ WjqVWKtSvd+TP/Dm6T2GtMC2WxRSy0u9fhXIkYWOBjy1tEBmLTA5hewDunC7zQNZ f98nFR0Xe5VoYdzlhADyO/MNovSm6V4uJZdYbedDcGjP0e7RtWZd14KWHC+JctwU kVMJfXx2EyxC1cTCv2s3aXHcIqLAowlEhjpSBv9l7u922oNRmzdtw/QzFLIOwKoH UjuDP1AK7V+URay2s21MBOBsgZz5g+dNPf7ThYURQMZ7CkcWpROn39YY/v8qJCs= =DCeq -----END PGP SIGNATURE----- --Apple-Mail=_18821777-BDDD-4687-9667-078ACD830CE0--