Particularly if this were to be used for a typed header, 32 bits would be insufficient to hold a date or the size of a multi-GB download. 64 bits seems sufficient currently, but it might still be worth letting this be implementation-dependent. This seems like another area where you might not want to tell a malicious attacker precisely what tripped you up. However, for all current purposes in the compression spec, 32 bits is probably more than sufficient. From: Fred Akalin [mailto:akalin@google.com] Sent: Monday, October 21, 2013 2:04 PM To: Martin Thomson Cc: Roberto Peon; Frédéric Kayser; HTTP Working Group Subject: Re: Security concern about open range integers (was: Question about: 4.1.1 Integer representation) I'm not sure I see the problem. While decoding a varint, you have to keep track of amount to right-shift the low 7 bits of the next octet. You can then check if doing so would overflow 32 bits, and abort if so. On Mon, Oct 21, 2013 at 10:23 AM, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote: On 20 October 2013 23:24, Fred Akalin <akalin@google.com<mailto:akalin@google.com>> wrote: > I think it's worth mentioning explicit upper bounds in the spec. Something > like any decoded varint must fit in 32 bits. I don't think that it makes sense to have a single maximum. Fitting the result into 32bits might be a nice goal, but that requires that you use only 6 octets of encoded length and make sure that it fits the mask 0xff 0x80 0xC0 0xff 0xff 0x0f. Or maybe 0xff 0x80 0xC0 0xff 0xff 0x0f7 if you are sign-bit averse. But only if that last byte has the 0x08 or 0x04 bit set. That is yucky. The alternative leaves you vulnerable to other attacks, especially the one where you get a long series of 0x80 bytes. https://github.com/http2/http2-spec/pull/291
Received on Monday, 21 October 2013 21:20:35 UTC