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ørgrav 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 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?593EE0FE-9309-11D8-A8CA-003065ABFD92>