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)
next prev parent 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