netdev - Re: [PATCH net-next] ipv6: Implement limits on hop by hop and destination options

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

Date:   Fri, 12 May 2017 18:02:36 -0700
From:   Tom Herbert <tom@...bertland.com>
To:     David Miller <davem@...emloft.net>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Martin Lau <kafai@...com>
Subject: Re: [PATCH net-next] ipv6: Implement limits on hop by hop and
 destination options

On Fri, May 12, 2017 at 8:38 AM, David Miller <davem@...emloft.net> wrote:
> From: Tom Herbert <tom@...bertland.com>
> Date: Wed, 10 May 2017 14:33:19 -0700
>
>> RFC 2460 (IPv6) defines hop by hop options and destination options
>> extension headers. Both of these carry a list of TLVs which is
>> only limited by the maximum length of the extension header (2048
>> bytes). By the spec a host must process all the TLVs in these
>> options, however these could be used as a fairly obvious
>> denial of service attack. I think this could in fact be
>> a significant DOS vector on the Internet, one mitigating
>> factor might be that many FWs drop all packets with EH (and
>> obviously this is only IPv6) so an Internet wide attack might not
>> be so effective (yet!).
>>
>> By my calculation, the worse case packet with TLVs in a standard
>> 1500 byte MTU packet that would be processed by the stack contains
>> 1282 invidual TLVs (including pad TLVS) or 724 two byte TLVs. I
>> wrote a quick test program that floods a whole bunch of these
>> packets to a host and sure enough there is substantial time spent
>> in ip6_parse_tlv. These packets contain nothing but unknown TLVS
>> (that are ignored), TLV padding, and bogus UDP header with zero
>> payload length.
>  ...
>> Default values are set to 8 for options counts, and set to INT_MAX
>> for maximum length. Note the choice to limit options to 8 is an
>> arbitrary guess (roughly based on the fact that the stack supports
>> three HBH options and just one destination option).
>
> So the maximum number of TLVs we could process is some function of the
> option count limit, and the number of padding TLVs that can be stuffed
> alongside of those 8 non-padding options?

Yes, if you count the one byte pad TLVs then maximum TLVs processed (#
times through the loop) with the default of 8 is 8 + 9*7= 71. The
padding TLVs are less expensive to process at least.

Function is:
N(max_non_pad) = (max_non_pad + 1) * 7 + max_non_pad