Subject: Re: TCP Port reuse related ...

From: "Ramesh Shankar" <[email-masked]>
Date: Thu, 27 Jan 2000 17:37:55 -0700

Hmm, looks like I was considering only the "passive mode" FTP cases and trying to figure out what the comments meant wrt it :-)).

Thanks,

S.R.

>>> Kacheong Poon <[email-masked]> 01/27/00 04:46PM >>>
> Well, if one is talking about well known ports, (0 - 1024), then you have
> the standard protection that comes with it: only super user can bind to such
> ports.

For example, nfsd is not listening on the above "well known" ports.  It
is listening on 2049, which is still well known to nfs clients.  There are
more well known services than the above 1-1024 port range can allow.  Anyway,
the kernel should provide a way to allow an app to make sure that all
requests to the port it bind() to should be sent to it only.

> In *any case*,  if I had done this:
> 
> socket1: bind(*, port #) (SO_REUSEADDR)
> socket2: bind(*, port #) (SO_REUSEADDR)
> listen(socket1)

Yup, this is a hole a server app can make.  It should not set SO_REUSEADDR
before doing a listen() if it wants to prevent this from happening.  But this
does not mean that the kernel should not enforce such a rule.  What the kernel
provides is a mechanism for apps to use.  Use it or not depends on what the
app wants to do.

> Then the sequence would have succeeded. Nothing prevents this from
> happening. Also, the standard behaviour is to allow the reuse of ports as
> long as SO_REUSEADDR has been used (i.e. it works this way in BSD, Winsock).
> With the UNIX variants, every one using a port has to use SO_REUSEADDR.
> Hence, if the first server that started off didn't use SO_REUSEADDR, this
> port stealing can't happen anyway. (With Winsock, only the later bind()ers
> have to specify SO_REUSEADDR, the first one doesn't have to).

Correct me if I am wrong.  Last time I checked FreeBSD code, it did not
check whether the original socket has SO_REUSEADDR set or not.  I think
what you mentioned above was not the way it worked.  Is it changed?  I
think it uses the user id to prevent the port stealing problem.  I am not
sure about Winsock.  Anyway, different OSes use different mechanisms to fill
this hole.

> What I don't get it is the comments about O(1) allocation for FTP servers
> etc. The implementation there seems to be related to standard SO_REUSEADDR
> case and I don't understand how an FTP server fits into this picture. (I
> even tried to check whether the Linux FTP server gives the same passive port
> # to multiple FTP clients, it doesn't seem to).

I think ftp server needs to create a data (port 20) connection.  So it has
to bind to port 20 repeatedly and it has to set SO_REUSEADDR.  Think of it
if there are a lot of such data connections in TIME_WAIT state.

							K. Poon.
							[email-masked]

---

From: der Mouse <[email-masked]>
Date: Thu, 27 Jan 2000 21:13:08 -0500 (EST)

>> socket1: bind(*, port #)
>> listen(socket1)
>> socket2: bind(IP1, port #)

> Suppose this is allowed and assume that socket1 belongs to a server
> app.  Then socket2, which belongs to a malicious app, can steal all
> service requests originated from IP1.

Right.  There is at least one server (either an NTP daemon or a DNS
daemon, I think) that binds not only a wildcard socket but also a
socket on each local address it can find, specifically to defeat this
attack.

Note that if the OS in question has the BSD notion of "privileged
ports", and the server in question is using such a port (and hence must
be running privileged), the malicious program must also be running
privileged to bind its socket - and if malicious programs are running
privileged, we've got worse problems than stolen network requests.

					der Mouse

			       [email-masked]
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Barney Wolff <[email-masked]>
Date: Fri, 28 Jan 2000 01:01 EST

I think the reason for binding to each address is so the (UDP) server
can send the response from the same address to which the request
was sent, which is otherwise difficult.

Barney Wolff  <[email-masked]>

> Date: Thu, 27 Jan 2000 21:13:08 -0500 (EST)
> From: der Mouse  <[email-masked]>
>