From owner-freebsd-security@FreeBSD.ORG Mon May 5 08:58: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 E2A5E937 for ; Mon, 5 May 2014 08:58:09 +0000 (UTC) Received: from mail.tyknet.dk (mail.tyknet.dk [144.76.253.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5FA9C1129 for ; Mon, 5 May 2014 08:58:08 +0000 (UTC) Received: from [IPv6:2a01:3a0:a:15::5] (unknown [IPv6:2a01:3a0:a:15::5]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id 6C68121570E for ; Mon, 5 May 2014 08:57:59 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail.tyknet.dk 6C68121570E DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1399280279; bh=k9oOy7PYT4vxm6t/dx8MEIb94qOaKkKG8R4qmzn4Kec=; h=Date:From:To:Subject; b=Zw7frJRy5M1HJvTeZLcx2S8430FnaO/rdaxOyATywp/R05ApHTHwNZct2756CvXeS //3qnV2omRXPBzfS3D4w8Nwqu4z5VM4JAWciMPlaiIjfYZOmgIoJEM6qBP1oQMeZdy fOXgOdi2eKr5LkmNkY79hJULgNun84jz8SwuXVw6uT2cZOxslic23EqHYStMSIMURr 8ABuvjedvaWBKCs9sr7ImOFvbdDwRkVnv/4NghHXaJPYGBuxSZuSbcLqMBCJLS2q5F Z31KSmlHev/5ohUyV9jGeEN8kSG6PfPph7rmYF83apZylQuC16UmtNcLUxdgfN2uNX G4NXhy/7A0VLA== Message-ID: <53675296.7060908@gibfest.dk> Date: Mon, 05 May 2014 10:57:58 +0200 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: FreeBSD-SA-14:08.tcp has nothing to do with tcp fragments! Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Mon, 05 May 2014 08:58:10 -0000 -----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-----