netdev - Re: [PATCH net] net: validate untrusted gso packets

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: <CAF=yD-+LATRZ0X2+gQmDDLkgLnwgPZxvJMCu=zWqdLsOvwhcRw@mail.gmail.com>
Date:   Tue, 16 Jan 2018 23:33:26 -0500
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Jason Wang <jasowang@...hat.com>
Cc:     Network Development <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Willem de Bruijn <willemb@...gle.com>
Subject: Re: [PATCH net] net: validate untrusted gso packets

On Tue, Jan 16, 2018 at 11:04 PM, Jason Wang <jasowang@...hat.com> wrote:
>
>
> On 2018年01月17日 04:29, Willem de Bruijn wrote:
>>
>> From: Willem de Bruijn<willemb@...gle.com>
>>
>> Validate gso packet type and headers on kernel entry. Reuse the info
>> gathered by skb_probe_transport_header.
>>
>> Syzbot found two bugs by passing bad gso packets in packet sockets.
>> Untrusted user packets are limited to a small set of gso types in
>> virtio_net_hdr_to_skb. But segmentation occurs on packet contents.
>> Syzkaller was able to enter gso callbacks that are not hardened
>> against untrusted user input.
>
>
> Do this mean there's something missed in exist header check for dodgy
> packets?

virtio_net_hdr_to_skb checks gso_type, but it does not verify that this
type correctly describes the actual packet. Segmentation happens based
on packet contents. So a packet was crafted to enter sctp gso, even
though no such gso_type exists. This issue is not specific to sctp.

>>
>> User packets can also have corrupted headers, tripping up segmentation
>> logic that expects sane packets from the trusted protocol stack.
>> Hardening all segmentation paths against all bad packets is error
>> prone and slows down the common path, so validate on kernel entry.
>
>
> I think evil packets should be rare in common case, so I'm not sure validate
> it on kernel entry is a good choice especially consider we've already had
> header check.

This just makes that check more strict. Frequency of malicious packets is
not really relevant if a single bad packet can cause damage.

The alternative to validate on kernel entry is to harden the entire segmentation
layer and lower part of the stack. That is much harder to get right and not
necessarily cheaper.

As a matter of fact, it incurs a cost on all packets, including the common
case generated by the protocol stack.