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]
Date:	Wed, 11 Feb 2015 21:24:28 -0800
From:	Tom Marshall <tom@...gn.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] net: ip: Do not allow connection to remote port zero

On Wed, Feb 11, 2015 at 08:06:14PM -0800, Eric Dumazet wrote:
> On Wed, 2015-02-11 at 16:58 -0800, Tom Marshall wrote:
> > Port zero is reserved according to IANA.
> > 
> > Note UDP sendto is already disallowed if dport is zero.
> 
> I have no idea why we should prevent such thing.

* It is marked "reserved" by IANA.

* UDP packets with dport=0 are already prevented from being sent.

* Many routers will either drop the packets or, worse, send back a RST to a
  SYN destined for port 0.

> There is nothing wrong sending a TCP frame with dport=0, even if
> practically it is not possible to setup a listener on such port using
> BSD API.

Then why not allow UDP packets with dport=0?



For background, I encountered this via a test fail in Google's Android CTS. 
Their test suite tries to ensure that a Java level connect with a specified
timeout functions properly by establishing a TCPv4 connection to a verified
unreachable address on the internet.  It happens to use port 0 as a
destination port.  I observed that sometimes this test succeeds and
sometimes it fails.  When it fails, tcpdump shows a RST coming back.  And
that RST is coming from a local router on one of the networks that I am
frequently on.

After doing some research and seeing the UDP sendto behavior, I figured it
would be good to have consistency between sendto() and connect(), and also
make it obvious to userspace that dport=0 is not permitted in any form.

Note that the latest CTS code does have a "fix" for this ... which was not
to switch ports, but to handle the case where ECONNREFUSED is returned
before the connect timeout expires... :/
--
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

Powered by blists - more mailing lists