netdev - Re: [PATCH 2/2] ipv6: don't deliver packets with zero length to raw sockets

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:   Fri, 21 Apr 2017 10:48:54 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     sd@...asysnail.net
Cc:     jbainbri@...hat.com, kuznet@....inr.ac.ru, jmorris@...ei.org,
        yoshfuji@...ux-ipv6.org, kaber@...sh.net, netdev@...r.kernel.org
Subject: Re: [PATCH 2/2] ipv6: don't deliver packets with zero length to
 raw sockets

From: Sabrina Dubroca <sd@...asysnail.net>
Date: Fri, 21 Apr 2017 12:01:12 +0200

> Hi Jamie,
> 
> 2017-04-21, 13:58:44 +1000, Jamie Bainbridge wrote:
>> IPv6 assumes there is data after the network header and blindly delivers
>> skbs to raw sockets without checking the presence of data.
>> 
>> With an application in a common loop where it checks select/poll/epoll
>> then ioctl(SIOCINQ/FIONREAD) is positive before continuing to
>> recvfrom(), this behaviour can cause the application to loop forever
>> on ioctl() because there is a zero-length skb to receive.
>> 
>> With this, it is very easy to make a Denial of Service attack by
>> crafting a packet which declares a Next Header in the IPv6 header but
>> does not actually supply a transport header and/or payload.
>> 
>> skb->len is already correctly set in ip6_input_finish() with pskb_pull()
>> so check this length before delivering zero data to raw sockets.
> 
> Isn't that changing behavior? recv() currently returns 0 when a packet
> that stops right after the IP header arrives. After this, the userspace
> program won't receive anything in this case?

Yes, just like UDP, zero length packets should be allowed and processed.

Not silently dropped.

And this would give us yet another behavioral difference between ipv4 and
ipv6, so no thanks...