Re: Compressed SVG? (and a couple of announcements)

On Thu, Sep 18, 2014 at 8:08 PM, Leonard Rosenthol <lrosenth@adobe.com>
wrote:

>  You’ve never seen (or been attacked by) a Zip Bomb (<
> https://en.wikipedia.org/wiki/Zip_bomb>) or HTML Decompression Bomb (<
> http://www.aerasec.de/security/advisories/html-bomb/>).   We (Adobe) have
> and as such any new file format that we design that involves compression or
> archiving we incorporate the length to avoid this.   Yes, you are correct,
> you can find other ways – but having the original length is quickest and
> best.
>

Let me put it this way: what would providing the original length in the
table allow for (against attacks) that not having them doesn't?  AFAIK what
Firefox does when decoding WOFF is to reject the font if any table has its
original length greater than some constant (2GB?).  Firefox can do the same
by refusing to allocate buffers larger than that size.



> As Sairus mentions, we would STRONGLY recommend (and in fact, will push
> for) this addition.
>

Works either way for me as long as Firefox is happy with breaking
compatibility with existing font format.  Bumping the major version of the
table just to get original size in on the other hand, IMO, is excessive.

behdad


> Leonard
>
>   From: Behdad Esfahbod <behdad@google.com>
> Date: Thursday, September 18, 2014 at 7:01 AM
> To: Sairus Patel <sppatel@adobe.com>
> Cc: "robert@ocallahan.org" <robert@ocallahan.org>, "
> public-svgopentype@w3.org" <public-svgopentype@w3.org>
> Subject: Re: Compressed SVG? (and a couple of announcements)
> Resent-From: "public-svgopentype@w3.org" <public-svgopentype@w3.org>
> Resent-Date: Thursday, September 18, 2014 at 7:02 AM
>
>    On Wed, Sep 17, 2014 at 7:43 PM, Sairus Patel <sppatel@adobe.com>
> wrote:
>
>>  I think solid security best practices suggest we also add the
>> uncompressed length of each SVGZ doc (see Adobe’s original proposal I
>> pointed to earlier in the thread).
>>
>
>  I don't think so.  HTTP Transfer-Encoding doesn't include the original
> length for example.  I never understood that argument.  Clients can use
> heuristics to compensate.  For example, a client can allocate an 8kb buffer
> on stack and try decompressing.  Only if that is not sufficient, they need
> to do something else.
>
>  Another approach would avoid allocating a full decompression buffer
> completely, by chaining a gzip decompression stream to the XML parsing
> library, completely obviating this issue.
>
>  Note that gzip has a max compression rate of around 1100, so it's not
> like a 1kb gzip buffer can explode to gigabytes either.
>
>  I don't think any action is needed here.  It's convenient to have the
> original buffer length in case of WOFF, but not needed for any security
> reason IMO, and certainly not for any reasons other than convenience.
>
>  behdad
>
>
>>  So it looks like we need an ‘SVG ‘ table with version 1 (current OFF
>> proposal is version 0), with an optional set of uncompressed lengths
>> (perhaps a particular “uncompressed length” can be set to 0 to indicate
>> that its corresponding SVG doc is not compressed). Since such a version 1
>> table using SVGZ would not be compatible with version 0 engines
>> (Mozilla’s), there would have to be some language indicating version 0 is
>> deprecated in some way or that engines may reject an SVGZ with version 0
>> due to security reasons. This way, Behdad and others can continue to use
>> SVGZ with version 0.
>>
>>  Sairus
>>
>>   From: Robert O'Callahan <robert@ocallahan.org>
>> Reply-To: Robert O'Callahan <robert@ocallahan.org>
>> Date: Tuesday, September 16, 2014 at 2:07 PM
>> To: Behdad Esfahbod <behdad@google.com>
>> Cc: Sairus Patel <sppatel@adobe.com>, "public-svgopentype@w3.org" <
>> public-svgopentype@w3.org>
>> Subject: Re: Compressed SVG? (and a couple of announcements)
>>
>>   On Wed, Sep 17, 2014 at 3:30 AM, Behdad Esfahbod <behdad@google.com>
>> wrote:
>>
>>>  As a concrete proposal, I like to suggest updating the spec to allow
>>> SVGZ where SVG is currently accepted, with no other changes.  WDYT?
>>>
>>
>>  That sounds OK I guess.
>>
>> Rob
>> --
>> oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
>> owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
>> osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
>> owohooo
>> osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
>> oioso
>> oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
>> owohooo
>> osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
>> ooofo
>> otohoeo ofoioroeo ooofo ohoeololo.
>>
>
>