netdev - Re: SO_REUSEADDR with UDP (again)

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

Message-ID: <1271155163.16881.244.camel@edumazet-laptop>
Date:	Tue, 13 Apr 2010 12:39:23 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Michal Svoboda <michal.svoboda@...nts.felk.cvut.cz>
Cc:	netdev@...r.kernel.org
Subject: Re: SO_REUSEADDR with UDP (again)

Le mardi 13 avril 2010 à 11:34 +0200, Michal Svoboda a écrit :
> Hello,
> 
> (redirected here from LKML)
> 
> I found SO_REUSEADDR on UDP sockets to behave somewhat nasty. If you
> create a UDP socket with that flag and bind it to a port, then anyone
> doing the same later will "steal" your packets, ie.
> 
> 1. process A binds to port 12345 with SO_REUSEADDR, packets to that port
>    go to process A

why process A sets SO_REUSEADDR ?

> 2. process B binds to port 12345 with SO_REUSEADDR, packets to that port
>    now go to process B

	Or not... this is implementation (un)defined.

> 3. A dies, fires up again, packets go back to A
        Or not. Not documented.
> 4. A dies, does not fire up, packets go to B, as if they were stacked
> 
> And this works even if A and B are owned by different users, thus anyone
> can "steal" packets from anyone as long as they use SO_REUSEADDR.
> However, in most programs that's the default.

Really ? They are very buggy then.

> 
> Furthermore, one can lock-out a particular source from being "stolen" by
> using connect() to that source, ie.
> 
> 1. process A binds to port 12345 with SO_REUSEADDR, gets the packets
> 2. B does the same, gets the packets, but also connect()s to the source
>    of the packets
> 3. A can now restart or try to bind again, but does not get the packets
>    (from that source)
> 
> (I haven't tested the case if A also issues a connect() even if it does
> not receive packets.)
> 
> All of this seems confusing to me, and the fact that users can steal
> packets from each other seems like a mild security risk. I've found some
> discussions about this from circa 2002, but the above cases were not
> mentioned. So - a problem or not?
> 
> 

Why do you use REUSEADDR ? This is doing what is documented.

       SO_REUSEADDR
              Indicates that the rules used in validating addresses  supplied
              in  a  bind(2) call should allow reuse of local addresses.  For
              AF_INET sockets this means that a socket may bind, except  when
              there is an active listening socket bound to the address.  When
              the listening socket is bound to  INADDR_ANY  with  a  specific
              port then it is not possible to bind to this port for any local
              address.  Argument is an integer boolean flag.


An UDP application wanting a port for its exclusive use dont set
REUSEADDR, or basically allows anybody to bind an udp socket to same
port, and potentially steal incoming frames.

REUSEADDR is usually used when an application has several sockets bound
to same port, but different IP addresses (or bound to different devices)



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html