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

Message-Id: <20170512.113847.1389407948502066394.davem@davemloft.net>
Date:   Fri, 12 May 2017 11:38:47 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     tom@...bertland.com
Cc:     netdev@...r.kernel.org, kafai@...com
Subject: Re: [PATCH net-next] ipv6: Implement limits on hop by hop and
 destination options

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?