From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 13:29:06 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0033616A4CE for ; Tue, 20 Apr 2004 13:29:05 -0700 (PDT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id C663343D1F for ; Tue, 20 Apr 2004 13:29:05 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i3KKT55l025203 for ; Tue, 20 Apr 2004 13:29:05 -0700 (PDT) Received: from [10.1.1.193] (nfw2.codefab.com [199.103.21.225] (may be forged)) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 3.0) with ESMTP id i3KKT4TK025848 for ; Tue, 20 Apr 2004 13:29:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <593EE0FE-9309-11D8-A8CA-003065ABFD92@mac.com> Content-Transfer-Encoding: quoted-printable From: Charles Swiger Date: Tue, 20 Apr 2004 16:28:56 -0400 To: freebsd-security@freebsd.org X-Mailer: Apple Mail (2.613) Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 20:29:06 -0000 On Apr 20, 2004, at 1:44 PM, Dag-Erling Sm=F8rgrav wrote: > Mike Tancsa 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