From owner-freebsd-security Fri Nov 21 16:14:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA26741 for security-outgoing; Fri, 21 Nov 1997 16:14:22 -0800 (PST) (envelope-from owner-freebsd-security) Received: from biggusdiskus.flyingfox.com (biggusdiskus.flyingfox.com [206.14.52.27]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA26732 for ; Fri, 21 Nov 1997 16:14:19 -0800 (PST) (envelope-from jas@flyingfox.com) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.5/8.8.5) id QAA05235; Fri, 21 Nov 1997 16:14:59 -0800 (PST) Date: Fri, 21 Nov 1997 16:14:59 -0800 (PST) From: Jim Shankland Message-Id: <199711220014.QAA05235@biggusdiskus.flyingfox.com> To: fenner@parc.xerox.com Subject: Re: new TCP/IP bug in win95 (fwd) Cc: Don.Lewis@tsc.tdk.com, security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bill Fenner writes: > Jim Shankland wrote: > >I can't think of any case in which it would > >be legal or desirable to have a TCP connection with (src-ip, src-port) > >equal to (dst-ip, dst-port) > > It's legal. I'm not convinced (yet). How could you ever implement this? Each endpoint of a TCP circuit needs a state structure (the TCB). So such a connection (like any TCP connection) would have 2 TCB's; but in this case, (local-ip, local-port) would be equal to (far-ip, far-port) in each TCB. How do you propose to tell the 2 TCB's apart? I.e., when a packet arrives, how do you know which of the 2 TCB's to associate it with? You certainly can't get into this state without spoofing: try to bind() a client-side (connecting) socket to a port on which a server is already listening, and you'll get EADDRINUSE. > For one thing, src-ip == dst-ip is not the only situation that will > cause this behavior on a multi-homed host; determining if this is an > evil packet takes a routing table lookup or an interface table search. Well, I don't think you can do it with one packet (Don Lewis points out it may be possible with two). If somebody spoofs a SYN packet from (ip-1, telnet) to (ip-2, telnet), for example, where both ip-1 and ip-2 are on the local machine, the response (SYN-ACK from (ip-2, telnet) to (ip-1, telnet)) will be dispacted to a TCB that is still in the LISTEN state, causing a reset. > It may also be that there's a whole class of problems that this bug is > only one symptom of, and finding the right fix rather than the > right-now fix could be important in the future. Agreed. I'd claim the "whole class of problems" is named "source address spoofing," and that there is no one "right fix." Rejecting packets with out-of-range ACK values before a connection is fully synchronized sounds like one right fix. Rejecting connections in which (src-ip, src-port) == (dst-ip, dst-port) sounds like another. And per-interface source-ip address screening sounds like another. There's probably quite a bit more to think about, here. Jim Shankland Flying Fox Computer Systems, Inc.