Date: Tue, 20 Apr 2004 16:28:56 -0400 From: Charles Swiger <cswiger@mac.com> To: freebsd-security@freebsd.org Subject: Re: TCP RST attack Message-ID: <593EE0FE-9309-11D8-A8CA-003065ABFD92@mac.com> In-Reply-To: <xzphdve35oa.fsf@dwp.des.no> References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <xzphdve35oa.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 20, 2004, at 1:44 PM, Dag-Erling Sm=F8rgrav wrote: > Mike Tancsa <mike@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=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?593EE0FE-9309-11D8-A8CA-003065ABFD92>