bugtraq - Solaris 10 Port Stealing Vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <1301339209.24744.36.camel@rush>
Date: Mon, 28 Mar 2011 15:06:49 -0400
From: "Chris O'Regan" <chris@...s.concordia.ca>
To: bugtraq@...urityfocus.com
Subject: Solaris 10 Port Stealing Vulnerability

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 <chris@...s.concordia.ca>
Senior Unix Systems Administrator, Academic IT Services
Faculty of Engineering and Computer Science
Concordia University, Montreal, Canada