bugtraq - RE: 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>] [thread-next>] [day] [month] [year] [list]

Message-ID: <1301519536.11189.69.camel@rush>
Date: Wed, 30 Mar 2011 17:12:16 -0400
From: "Chris O'Regan" <chris@...s.concordia.ca>
To: Jim Harrison <Jim@...tools.org>
Cc: "bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>
Subject: RE: Solaris 10 Port Stealing Vulnerability

On Wed, 2011-03-30 at 14:20 +0000, Jim Harrison wrote:
> Interesting...
> Windows also has similar functionality offered via .NET services (Net.Tcp Port Sharing http://msdn.microsoft.com/en-us/library/ms734772.aspx), but this is only available through .NET API; not directly through Winsock or AFD.  I suspect the BSD implementation you discovered has similar goals in mind (expanding the TCP socket limits), but didn't go as far with the solution.
> The BSD folks indicated that this is "by-design" - did they also point you toward any management API beyond making the socket "protected"??

I don't believe it is anything like the .NET functionality you mention.
After reading the article, I get the impression that this is specific to
HTTP and is a combination of virtual hosting and reverse proxy. (I may
be wrong, I only skimmed through the document.)

I can see why this [BSD] functionality might desired. If you have a
server with several interfaces and/or alias addresses, you can bind a
service to specific address/port for multiple interface/alias (each an
independent process running as a different user and serving different
content -- that's fine, we do this all the time) and have a "default"
service listening on the wildcard interface which will respond where
there is not specific address/port service. But unless you are designing
a service to function this way, it's a very bad idea to enable this
feature by default, and really, it should only be enable on the port
where it is desired.

Imagine if you find a Solaris system running a web server that has a
remote exploit which allows for the execution of arbitrary code. If the
web server happens to be listening on the wildcard interface than you
can very easily insert your own web server in front of it!

-- 
Chris O'Regan <chris@...s.concordia.ca>
Senior Unix Systems Administrator, Academic IT Services
Faculty of Engineering and Computer Science
Concordia University, Montreal, Canada