W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

RE: Security concern about open range integers (was: Question about: 4.1.1 Integer representation)

From: Mike Bishop <Michael.Bishop@microsoft.com>
Date: Mon, 21 Oct 2013 21:20:05 +0000
To: Fred Akalin <akalin@google.com>, Martin Thomson <martin.thomson@gmail.com>
CC: Roberto Peon <grmocg@gmail.com>, Frédéric Kayser <f.kayser@free.fr>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <7cf6fe9d12c04a7d8a96cc9cef857331@BY2PR03MB025.namprd03.prod.outlook.com>
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.


Received on Monday, 21 October 2013 21:20:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:19 UTC