netdev - Re: Sending short raw packets using sendmsg() broke

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: <1456876822.7064.36.camel@linux.intel.com>
Date:	Wed, 02 Mar 2016 00:00:22 +0000
From:	Alan Cox <alan@...ux.intel.com>
To:	Willem de Bruijn <willemdebruijn.kernel@...il.com>,
	David Miller <davem@...emloft.net>
Cc:	Heikki Hannikainen <hessu@....iki.fi>,
	Network Development <netdev@...r.kernel.org>,
	Willem de Bruijn <willemb@...gle.com>
Subject: Re: Sending short raw packets using sendmsg() broke

> More thorough validation of the header contents is not necessarily
> hard. The following validates the address, including optional
> repeaters.
> 
>   static bool ax25_validate_hard_header(const char *ll_header,
>                                        unsigned short len)
>   {
>          ax25_digi digi;
> 
>          return !ax25_addr_parse(ll_header, len, NULL, NULL, &digi,
> NULL, NULL);
>   }

This also breaks because there is a KISS header byte on an AX.25
transmission and it is valid to send a KISS control frame via
SOCK_PACKET but it cannot be generated by other protocols.

Basically everything hitting an AX.25 port is either a zero byte
followed by an AX.25 frame, or a KISS frame the first of which is non
zero and which is used to set parameters on the radio side.

The AX.25 device level drivers are simply written to be robust if
thrown partial frames.

The other thing that concerns me about this added logic in general is
that you are also breaking test tools that want to deliberately send
corrupt frames to certain classes of interface. I'm not sure how big an
issue that is given we always for example padded ethernet frames
properly, but the more validation we do for a privileged interface the
more we prevent applications for testing network behaviour from being
able to run on Linux. Possibly there should be a CAP_SYS_RAWIO test but
making it impossible is a bad step.

Alan