OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Re: Insecurities in Non-exclusive Scoket Binding

From: Marc Slemko (marcsznep.com)
Date: Mon Mar 10 2003 - 12:18:05 CST


On Sun, 10 Mar 2003, Firosh Ummer wrote:

> I've written a paper on the risks in non-exclusive socket binding, and how
> developers can mitigate the risks. Using MySQL as an illustration, the
> paper discusses how attackers could potentially hijack sockets bound by a
> higher privilged process, and inject commands in the stream. This is a
> local privilege escalation attack, and is easier to do than one would
> imagine.
>
> Link to the paper: http://www.paladion.net/papers/socketbinding.pdf
>
> Socket hijacking itself is not new - it has been cited in several sources
> on the net. What I find disturbing is how easy it is for an attacker to
> hijack a privileged connection and then insert privileged commands,
> running with very low privileges.

This is a fairly old, well understood issue on most unix platforms.
That is why you will find nearly any modern unix does not allow
more specific port binding unless it is done by the same user as the
wildcard bind, or by root.

None of this prevents exploitation by simply finding some way to
kill the service listening on the port, or by exploiting a race
condition at startup or restart. This is one of the reasons why
the concept of privileged ports was, and still is, extremely important
on systems with untrusted users.

As for windows... I really couldn't see anyone recommending you run
any services like that on a windows box where untrusted users have
access. There are simply so many other ways to escalate privileges.

I'm not sure the windows specific SO_EXCLUSIVEADDRUSE option is
practical due to mindboggling limitations. Apparently it prevents
rebinding if there are _any_ sockets open to that port, even if
they are in FIN_WAIT, FIN_WAIT_2, or LAST_ACK. To be able to unbind
and then rebind the port when restarting, etc. the application must
jump through unreasonable hoops to be able to reliably use
SO_EXCLUSIVEADDRUSE.

See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/using_so_exclusiveaddruse.asp
for details, starting with "an important caveat ..."