From owner-freebsd-security Sat Nov 22 20:24:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA16996 for security-outgoing; Sat, 22 Nov 1997 20:24:06 -0800 (PST) (envelope-from owner-freebsd-security) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id UAA16991 for ; Sat, 22 Nov 1997 20:24:02 -0800 (PST) (envelope-from fenner@parc.xerox.com) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <53511(5)>; Sat, 22 Nov 1997 20:23:30 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177476>; Sat, 22 Nov 1997 20:23:27 -0800 To: "Charles M. Hannum" cc: BUGTRAQ@netspace.org, fenner@parc.xerox.com, security@freebsd.org Subject: Re: "LAND" Attack Update In-reply-to: Your message of "Sat, 22 Nov 97 11:47:20 PST." Date: Sat, 22 Nov 1997 20:23:15 PST From: Bill Fenner Message-Id: <97Nov22.202327pst.177476@crevenia.parc.xerox.com> Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Charles M. Hannum" wrote: >The FreeBSD hack to `fix' (or not allow) self-connects DOES NOT WORK >FOR MULTIHOMED HOSTS. It's still possible to crash a multihomed >FreeBSD system by locally running a program that connects a TCP socket >to itself. Can you expand on that a little? I first thought that it was possible to get this pathology to happen on a multi-homed host by using two different interfaces as the source and destination, but haven't yet been able to exploit it. (You'd expect that it would work on single-homed hosts too, with a source address of 127.0.0.1, but I can't get that to cause trouble either). It's not possible to do a self-connect using two different interfaces, since if you bind to an interface then you also have to connect to that interface or it's not a self-connect, so I'm not sure what you mean by locally running a program that connects a TCP socket to itself. Assuming that you meant locally running something like land.c which sends a packet forged from one interface destined for another, I've tried that. On a host which is vulnerable to the "standard" attack, I see the following packets when I forge a SYN from one interface address to the other: 20:21:32.187983 InterfaceA.telnet > InterfaceB.telnet: S 1:1(0) win 1024 (ttl 255, id 69) 20:21:32.188092 InterfaceB.telnet > InterfaceA.telnet: S 95950695:95950695(0) ack 2 win 16384 (DF) (ttl 64, id 409) 20:21:32.188113 InterfaceA.telnet > InterfaceB.telnet: R 2:2(0) win 16384 (ttl 64, id 410) Bill