Date: Fri, 23 Apr 2004 21:10:54 -0400 From: Chuck Swiger <cswiger@mac.com> To: Darren Reed <avalon@caligula.anu.edu.au> Cc: freebsd-security@freebsd.org Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) Message-ID: <4089BE9E.8080901@mac.com> In-Reply-To: <200404220829.i3M8TpcB022690@caligula.anu.edu.au> References: <200404220829.i3M8TpcB022690@caligula.anu.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4089BE9E.8080901>