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

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.

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

Leonard

From: Behdad Esfahbod <behdad@google.com<mailto:behdad@google.com>>
Date: Thursday, September 18, 2014 at 7:01 AM
To: Sairus Patel <sppatel@adobe.com<mailto:sppatel@adobe.com>>
Cc: "robert@ocallahan.org<mailto:robert@ocallahan.org>" <robert@ocallahan.org<mailto:robert@ocallahan.org>>, "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>>
Subject: Re: Compressed SVG? (and a couple of announcements)
Resent-From: "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto: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<mailto: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<mailto:robert@ocallahan.org>>
Reply-To: Robert O'Callahan <robert@ocallahan.org<mailto:robert@ocallahan.org>>
Date: Tuesday, September 16, 2014 at 2:07 PM
To: Behdad Esfahbod <behdad@google.com<mailto:behdad@google.com>>
Cc: Sairus Patel <sppatel@adobe.com<mailto:sppatel@adobe.com>>, "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto: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<mailto: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.