Netdev List
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Michal Svoboda <michal.svoboda@agents.felk.cvut.cz>
Cc: netdev@vger.kernel.org
Subject: Re: SO_REUSEADDR with UDP (again)
Date: Tue, 13 Apr 2010 12:39:23 +0200	[thread overview]
Message-ID: <1271155163.16881.244.camel@edumazet-laptop> (raw)
In-Reply-To: <20100413093408.GA16595@myhost.felk.cvut.cz>

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)




  reply	other threads:[~2010-04-13 10:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-13  9:34 SO_REUSEADDR with UDP (again) Michal Svoboda
2010-04-13 10:39 ` Eric Dumazet [this message]
2010-04-13 11:27   ` Michal Svoboda
2010-04-13 12:21     ` Eric Dumazet
2010-04-13 16:23       ` Michal Svoboda
2010-04-13 16:36         ` Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1271155163.16881.244.camel@edumazet-laptop \
    --to=eric.dumazet@gmail.com \
    --cc=michal.svoboda@agents.felk.cvut.cz \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox