From owner-freebsd-security@FreeBSD.ORG Thu May 8 00:19:10 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 309A09E2 for ; Thu, 8 May 2014 00:19:10 +0000 (UTC) Received: from st11p09mm-asmtp001.mac.com (st11p09mm-asmtp001.mac.com [17.164.24.96]) by mx1.freebsd.org (Postfix) with ESMTP id E94C5A2 for ; Thu, 8 May 2014 00:19:09 +0000 (UTC) MIME-version: 1.0 Received: from [10.71.14.16] (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N580041O8R1RE90@st11p09mm-asmtp001.mac.com> for freebsd-security@freebsd.org; Wed, 07 May 2014 23:18:40 +0000 (GMT) Content-type: multipart/signed; boundary="Apple-Mail=_18821777-BDDD-4687-9667-078ACD830CE0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Re: FreeBSD-SA-14:08.tcp has nothing to do with tcp fragments! From: Kimmo Paasiala In-reply-to: <53675296.7060908@gibfest.dk> Date: Thu, 08 May 2014 02:18:32 +0300 Message-id: References: <53675296.7060908@gibfest.dk> To: Thomas Steen Rasmussen X-Mailer: Apple Mail (2.1874) X-MANTSH: 1TEIXWV4bG1oaGkdHB0lGUkdDRl5PWBoaEhEKTEMXGx0EGx0YBBIZBBsSEBseGh8 aEQpYTRdLEQptfhcaEQpMWRcbGhsbEQpZSRcRClleF2hjeREKQ04XSxsZGmJCH2lmHX9jGXhzB x4dGBkbEk8fEQpYXBcZBBoEGxsHTU4fGBgYGUsFGx0EGx0YBBIZBBsSEBseGh8bEQpeWRdhRW1 6WBEKTEYXYmtrEQpDWhcSEgQbEx8EGxgSBBkZEQpEWBcYEQpESRcbEQpCRRdmfX8TTW9cYGUaE hEKQk4Xa0UaUlAeQ1xZXGgRCkJMF25NHXlZY2RofhhGEQpCbBdhQHxTbEsfGGR7fhEKQkAXbGd FTVJGa3pnZkkRCnBoF2McSUdAf395XX5CEQpwaBdvQGMTfBxFcxJ/ZBEKcGgXYhoccHlNWlMfY GYRCnBoF24cX11mXmJnGUBNEQpwaBd6a2USRWJBc2QdaxEKcH8XbRsaeXttW39IRW4RCnBfF2l cE2RNbH5ZRXtPEQpwXxdtSBl5AW0fTnlGaxEKcF8XYUBcARpoEmZMWEURCnBrF3pFU1pbcm9vb 05NEQpwSxdiaXITWF1cZ21TcxEKcGsXbwFcQmtAYmVNelMRCnBsF21nbgUfYU5hHFsbEQpwTBd oaVpzGR4aexxiUhE= X-CLX-Spam: false X-CLX-Score: 1011 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96,1.0.14,0.0.0000 definitions=2014-05-07_06:2014-05-07,2014-05-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=4 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405070271 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 00:19:10 -0000 --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 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--