On Apr 20, 2004, at 1:44 PM, Dag-Erling Sm=F8rgrav wrote: > Mike Tancsa <[email protected]> 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=20 vulnerability and it's difficult to perform this type of attack under=20 most circumstances without being able to sniff the traffic going by. =20 (Basicly, sending a RST is a simple form of data injection via the=20 classic man-in-the-middle attack. ACKs and RSTs count as data, too. =20 :-) Egress filtering is a fine idea, but I don't see that it would help=20 much in this case. Ingress filtering-- ie, traffic from IP block=20 x.x.x.x/yy must come via interface Z-- and blocking source-routing=20 would seem to be more helpful. It's not clear to me that this advisory is particularly relevant to=20 FreeBSD in the sense that there is some change that ought to be made at=20= the OS-level to mitigate against such attacks: using IPsec, SSL port=20 forwarding, and such are already well-supported under FreeBSD. Using a tiny window (say ethernet MTU or smaller) would greatly=20 increase the amount of work an attacker has to do to create a valid RST=20= to zap an open connection, admittedly at the cost of adding a lot of=20 latency to such TCP connections. Hmm, how about a mechanism that would=20= let one control the maximum TCP window size the system will permit on a=20= per-host or per-network-block basis? --=20 -Chuck _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"