TCP RST attack

[Charles Swiger]

On Apr 20, 2004, at 1:44 PM, Dag-Erling Smørgrav wrote:
> Mike Tancsa <mike at sentex.net> writes:
>> http://www.uniras.gov.uk/vuls/2004/236929/index.htm
>
> The advisory grossly exaggerates the impact and severity of this
> fea^H^H^Hbug.  The attack is only practical if you already know the
> details of the TCP connection you are trying to attack, or are in a
> position to sniff it.  The fact that you can attack a TCP connection
> which passes through a network you have access to sniff should not be
> a surprise to anyone; the remaining cases require spoofing of a type
> which egress filtering would prevent, if only people would bother
> implementing it.

My take on this is pretty close to yours: this isn't a new 
vulnerability and it's difficult to perform this type of attack under 
most circumstances without being able to sniff the traffic going by.  
(Basicly, sending a RST is a simple form of data injection via the 
classic man-in-the-middle attack.  ACKs and RSTs count as data, too.  
:-)

Egress filtering is a fine idea, but I don't see that it would help 
much in this case.  Ingress filtering-- ie, traffic from IP block 
x.x.x.x/yy must come via interface Z-- and blocking source-routing 
would seem to be more helpful.

It's not clear to me that this advisory is particularly relevant to 
FreeBSD in the sense that there is some change that ought to be made at 
the OS-level to mitigate against such attacks: using IPsec, SSL port 
forwarding, and such are already well-supported under FreeBSD.

Using a tiny window (say ethernet MTU or smaller) would greatly 
increase the amount of work an attacker has to do to create a valid RST 
to zap an open connection, admittedly at the cost of adding a lot of 
latency to such TCP connections.  Hmm, how about a mechanism that would 
let one control the maximum TCP window size the system will permit on a 
per-host or per-network-block basis?

-- 
-Chuck