EXTERNAL: OSError: [Errno 48] Address already in use

[Peter J. Holzer]

On 2018-06-30 14:01:56 -0700, Dan Stromberg wrote:
> On Sat, Jun 30, 2018 at 11:19 AM, Peter J. Holzer <hjp-python at hjp.at> wrote:
> > On 2018-06-28 18:04:16 -0700, Dan Stromberg wrote:
> > > If someone else comes along soon after and starts a different echo server
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > process Q at tcp/5555 on the same server, it starts up immediately if P
> > > used SO_REUSEADDR.
> > >
> > > Then initiate a connection from the same (or different) client machine to
> > > process P (which no longer exists).  Q gets the data intended for P.
> >
> > I don't think this is the issue TIME_WAIT is intended to prevent.
[...]
> > Secondly, it depends on the attacker not knowing about
> > SO_REUSEADDR, which seems overly optimistic.
> >
> Not really, no.  People on remote machines know little about process
> bounces.

But the attack you described isn't remote. It is performed by another
user on the same machine.

> And it's pretty easy to write a script that will check if a process is
> up repeatedly, starting a daemon when its not.

Right. This is something the attacker can do (and I would assume they
do).

> And you don't have to know about SO_REUSEADDR to write that script.

No. But if the attacker does know about SO_REUSEADDR they can start
their own server as soon as the notice that the server is down.
Otherwise they have to wait for two minutes.

Actually, I overlooked something: If you don't use SO_REUSEADDR, but the
attacker does, you have to wait, but the attacker doesn't - so this
gives a huge advantage to the attacker. If you do use SO_REUSEADDR, at
least you are an equal footing.


> OTOH, having to wait 2 minutes before you can restart your server is a
> > nuisance. Therefore, everybody uses SO_REUSEADDR.
> >
> During development, it's a good practice to setsockopt SO_REUSEADDR.
> 
> In production, different rules may or may not apply.  On multiuser systems,

In production, being able to restart a failed server quickly is usually
more important than to prevent a very low probability mixup on the TCP
level. Especially as you can't rely on TCP for integrity and
confidentiality anyway and have to put an extra layer (typically TLS)
for that on top.

> it's more important than on most of today's single-purpose virtual machines.
> 
> Some people feel that "security issues" must all be religiously 100%
> avoided completely, or they'll offend the computer gods.  This evidences a
> lack of understanding about the practical aspects of security issues.
> Security is very much a spectrum - multidimensional even.

I agree fully. The old adage that "security is binary" is utter
balderdash. However, I do feel that we should only call something a
"security feature" if it actually increases security. Not using
SO_REUSEADDR doesn't - quite the opposite.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180630/9f707e7c/attachment.sig>