RE: Ports 0-1023?

["Dawes, Rogan (ZA - Johannesburg)" <rdawes () deloitte co za>]

For what it is worth, there is a package on freshmeat that does exactly
this.

It runs in two components, a root owned one that checks ACL's (text files)
and actually binds the port, and a LD_PRELOAD ed library that replaced the
bind call to use a Unix socket mechanism to speak to the root daemon, and
get an fd from it.

Can't remember the name of the program, but it was there on freshmeat not
too long ago.

Rogan

> -----Original Message-----
> From: Dan Kaminsky [mailto:dan () doxpara com]
> Sent: 04 July 2002 12:38
> To: Blue Boar
> Cc: vuln-dev () securityfocus com
> Subject: Re: Ports 0-1023?
>
>
> Blue Boar wrote:
>
> > Is there any point in needing to be root in order to 
> allocate the low 
> > ports on unix-like systems, anymore?  Could we get away 
> from having to 
> > have some daemons even have a root stub in order to listen on a low 
> > port?  What would break, and what new holes would be 
> created?  Could 
> > some sort of port ACL simply be used that says a particular UID can 
> > allocate a particular range of ports?
> >
> > Discuss.
> >
> >                             BB
> BB--
>
>    I see your logic -- remote hosts can't depend on a root account 
> actually serving the daemon(hell, they can't depend on a 
> genuine TCP/IP 
> implementation serving the daemon), so what's the point of 
> requiring the 
> host to actually be root?  There are indeed many apps that have no 
> requirement for root privs save for the low port, why not remove that 
> requirement and drop the root req?  
>
>     Ah, but there's actually one very good reason to have the 0-1023 
> block around.  If I'm a local user, and I discover a way to 
> DoS a given 
> service such that it drops the socket, I can hijack the port and all 
> associated connections.  There's a decent shit-ton of SMTP 
> attacks that 
> work this way(drop sendmail, start picking up all mail that travels 
> through the host).
>
>     A standard root stub that *itself* executes arbitrary 
> apps -- root 
> owned, user operated*-- and then handles port forwarding to 
> them would 
> be a sufficiently generic solution...no kernel req's either.  I'd be 
> describing inetd, of course, except that the executable 
> wouldn't spawn 
> per connection...rather, it'd run a library preload against bind() on 
> the child process and enforce some random port (on 127.0.0.1) as the 
> actual listener.  Then it'd be a trivial matter of bouncing incoming 
> connections to the new local port.  If a hijacker did show up, he 
> wouldn't know which >1023 port to grab, and it wouldn't 
> matter because 
> the new bind would just pick something not already taken.
>
>     Hell, we could probably get people to run something like 
> this just 
> for the auto-daemon-restart capacity alone.
>
>  Yours Truly,
>
>     Dan Kaminsky
>     DoxPara Research
>     http://www.doxpara.com
>
> * echo "kid tested, mother approved" | unix