Re: bind() Security Problems

[dsiebert () icaen uiowa edu (dsiebert () icaen uiowa edu)]

> Sigh,
>
> I am not on any of these security lists but I have just been forwarded this
> alert about bind().
>
> This is a "feature" of IP Multicast support. I reported this bug in November
> 1993 on the IP Multicast workers mailing list, and directly to Steeve Deering.
>
> This feature was deliberately added to the (previously secure) BSD networking
> code by Steeve Deering (or at any rate one of the IP multicast people working
> with him) in 1992 or 1993 because of the way that IP Multicast works. Since IP
> multicast uses UDP all the recipients of a multicast session world wide must
> be using the same UDP port number. Since global agreement on free port numbers
> is not practical it was made possible for an application to get access to a
> particular UDP port irrespective of its use elsewhere on the same machine.
>
> Most vendors (e.g. Digital Unix) have not accepted this hole and only permit
> sharing of the same port when ALL of the sockets involved have SO_REUSEADDR
> set. This works reasonably well in practice since port numbers chosen for
> multicast sessions are above the range normally cyclicly allocated to other
> applications.
>
> I have not been following IP multicast implementation work so I have no idea
> at what stage (or even whether) this fix was adopted.


Even allowing a bind() to a port when all sockets involved have SO_REUSEADDR
set isn't very workable.  inetd will do this by default, so any server you
have in inetd can be hijacked.  At least the privileged port range provides
some protection, otherwise you could hijack telnet, rlogin, etc.!  Most other
servers (like the X server, which is outside the priviledged range) will do
this as well, to avoid the "Address is already in use" problem when restarted.
A way to get around the problem would be to have inetd make separate bindings
to all available addresses on the machine, rather than to the wildcard
address, but that will raise the number of open sockets quite a bit.  By a
really large amount on servers with lots of interfaces.

Doesn't multicast use addresses in the 224.x.x.x range?  Why can't a bind() to
that address range be allowed, on a port in use elsewhere?  This shouldn't
allow you to hijack connections on a previously bound port, but would still
allow multicast to work.  Or maybe the semantics of multicast need to be
changed under Unix, requiring some sort of setsockopt to put a socket into
multicast mode to allow this sort of thing.  Regular TCP and UDP were here
first, I don't see why we should allow such a clear violation of security for
IP multicast.  I'm sorry, but I don't think its important enough for this, the
end does not justify the means, IMHO!

How long before someone comes up with an exploit of X that intercepts the
incoming connections to the X server, getting around the security provided by
the magic cookie mechanism?

--
Doug Siebert
dsiebert () icaen uiowa edu