From owner-freebsd-security@FreeBSD.ORG Fri Apr 23 18:11:04 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3792316A4CE for ; Fri, 23 Apr 2004 18:11:04 -0700 (PDT) Received: from out012.verizon.net (out012pub.verizon.net [206.46.170.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB67243D53 for ; Fri, 23 Apr 2004 18:11:03 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([68.160.247.127]) by out012.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040424011103.QIPB18295.out012.verizon.net@mac.com>; Fri, 23 Apr 2004 20:11:03 -0500 Message-ID: <4089BE9E.8080901@mac.com> Date: Fri, 23 Apr 2004 21:10:54 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Darren Reed References: <200404220829.i3M8TpcB022690@caligula.anu.edu.au> In-Reply-To: <200404220829.i3M8TpcB022690@caligula.anu.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out012.verizon.net from [68.160.247.127] at Fri, 23 Apr 2004 20:11:02 -0500 cc: freebsd-security@freebsd.org Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2004 01:11:04 -0000 Darren Reed wrote: > In some mail from Mike Silbersack, sie said: [ ... ] >> Are you suggesting that we use the strict check during the ESTABLISHED >> phase, and the window-wide check during all other phases? > > Possibly :) > > I don't think it is important for session setup, but at the end of a > session, you generally want it to disappear from your connection table > sooner rather than later, right ? My take on this is that connection setup and teardown phases are generally present (and thus vulnerable to attack) for a very short time interval compared with the time ESTABLISHED connections may persist, so using a strict check for that phase makes sense. > Furthermore, you're more likely to get a RST after a FIN has been > sent, by either party, if you send another ACK because the other > guy has decided to remove the socket already. Does this make > sense ? Yes. > Although this makes me wonder, what's the implication here for FIN > packets - is there none ? The draft refers to SYNs (which do get > special treatment) and RSTs (just more violent FIN packets.) It's not clear to me that under the circumstances required for this attack, there is much difference between injecting a RST or a FIN, or anything else, for that matter: if you know or guess IP addresses, ports, and guess a sequence # in the window, you can inject a packet of data, too. That's enough to mangle any application-layer checksumming.... > If someone injects a FIN packet the way they would have done a RST, > what are the implications ? A FIN seems likely to be dropped as duplicate data: Segments are processed in sequence. Initial tests on arrival are used to discard old duplicates, but further processing is done in SEG.SEQ order. If a segment's contents straddle the boundary between old and new, only the new parts should be processed. A packet containing a FIN is unlikely to match the seq # exactly, and thus is likely to be overwritten by authentic packets, particularly a bare FIN. If you send a lot of data in the packet, perhaps it's more likely that your packet has some data that's accepted and thus the FIN gets processed, but big packets take longer for the attacker to send to send. -- -Chuck