[Spread-users] SO_REUSEADDR Final Chapter?

David Shaw dshaw at akamai.com
Fri Sep 21 15:21:13 EDT 2001


On Fri, Sep 21, 2001 at 10:24:02AM -0400, Jonathan Stanton wrote:

> BSDI 4.0.1
> Allow double binds when programs run as either same or different users
> when REUSEADDR is set. --This is the security risk case.
> 
> Solaris 5.7 x86
> Allow double binds when programs run as either same or different users
> when REUSEADDR is set. --This is the security risk case.

Even on those two platforms, there is only a security risk when the
"real" listener is listening on INADDR_ANY.  In that case, the snooper
can bind to the actual IP address and steal connections.  If the
"real" listener is bound to the actual IP address, there is nothing
the snooper can do.  They can bind to INADDR_ANY, but will not get any
connections as long as the "real" program is running.

> So based on this it would seem using REUSEADDR is safe on linux and
> freebsd 4, is not safe on bsdi 4.0.1 and solaris 5.7 and is unknown on
> others. 
> 
> Any suggestions as to how to best handle this in Spread? 

Coming up with a solution that hides the problem from the end user is
probably not a good idea: it's prone to error, and doesn't take into
account that the end user may have a different threat model than you
are designing a defense against.

I would do two things:

1) If the config file gives a specific interface (i.e. not
   INADDR_ANY), then enable REUSEADDR.  If it does not give a specific
   interface (i.e. INADDR_ANY) then do not enable REUSEADDR.

2) Add a config file option to force REUSEADDR on or off which
   overrides the setting from #1.

The benefits of this scheme is that you don't need to figure out the
right thing to do via autoconf tests as the rule in #1 is always safe
no matter what the platform.

#2 gives users with different situations the ability to do the right
thing for them without having an inappropriate security model forced
on them.  For example - what if the box in question has no user logins
at all?

David

-- 
David Shaw          |  Technical Lead
<dshaw at akamai.com>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 524 bytes
Desc: not available
Url : http://lists.spread.org/pipermail/spread-users/attachments/20010921/507f7f87/attachment.bin 


More information about the Spread-users mailing list