linux-kernel - Re: Sending UDP packets to port 0

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>] [day] [month] [year] [list]

Date:	Sun, 22 Jun 2008 03:02:52 -0700 (PDT)
From:	Alan Jenkins <aj504@...york.ac.uk>
To:	"Christian P. Schmidt" <schmidt@...add.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Sending UDP packets to port 0

Christian P. Schmidt wrote:
> Hi all,
>
> I know that the kernel forbids sending UDP packets to port 0. Is there a
> specific reason for this?

_Source_ port 0 is treated specially in the sockets implementation,
though I'm not sure  whether this is an intended feature of the API
(manpages don't mention it).  If you say "bind to port 0", you get an
arbitrary unused port instead, which is potentially useful.

> I'm asking because I regularly need to access a device that asks for
> tftp files using port 0 as source. To use these devices I'm using a
> kernel with removed port 0 checks.
>
> I read RFC 768, and it does not explicitly forbid the use of port 0 as
> far as I can see. It only says that if unused, 0 is to be inserted.

1. No, it only says that about the source port.
2. The only way to tell whether the field is "unused" is to check for
a 0 value.

> RFC 1350 (TFTP) even states explicitly:
> The transfer identifiers (TID's) used by TFTP are passed to the Datagram
> layer to be used as ports; therefore they must be between 0 and 65,535.
>
> In my understanding, and apparently that of the authors of the
> appliance's tftp client implementation, this marks port 0 as valid.

They're a bit mad then.  RFC1700 marks port 0 as "reserved" (other
unused ports are marked "unassigned").

I hope that explains why most sane people would avoid using port 0.  I
can't think of a specific reason for forbidding port 0 as a
destination; it's just generally not expected (and there was no reason
to allow it).  I think you need to be more specific if you hope to
have this check removed in mainline though.

Which TCP/IP stacks is the device tested/supported against?  Are you
saying Windows or some other OS lets you send to port 0?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/