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
| ||
|
Message-ID: <CALx6S35=3aiP3ip0GabnqbOFS=NFY0zvjPne_WJ_Y9J6ZpPe+w@mail.gmail.com> 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
Powered by blists - more mailing lists