Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Nov 1997 16:14:59 -0800 (PST)
From:      Jim Shankland <jas@flyingfox.com>
To:        fenner@parc.xerox.com
Cc:        Don.Lewis@tsc.tdk.com, security@freebsd.org
Subject:   Re: new TCP/IP bug in win95 (fwd)
Message-ID:  <199711220014.QAA05235@biggusdiskus.flyingfox.com>

next in thread | raw e-mail | index | archive | help
Bill Fenner <fenner@parc.xerox.com> writes:

> Jim Shankland <jas@flyingfox.com> 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711220014.QAA05235>