netdev - Re: [PATCH] net: ip: Do not allow connection to remote port zero

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: <20150212052428.GB10785@eden.sea.cyngn.com>
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