Re: CALL for DISCUSSION: eXIf 20170115

On Wed, Feb 1, 2017 at 6:37 AM, Willem van Schaik <[email protected]> wrote:
>
> btw, I stated nowhere that adding deflate to a PNG decoding program
> would add 1000 lines of code :-)

When *I* do it it's 150 lines of commented code.  Bear in mind that I
have written this code many times before so am very aware of all the
pitfalls and security issues.  I still make mistakes, but I write code
with internal asserts that flush out the problems with adequate
testing.  These days I can do it in maybe half a day, but originally
it took weeks if not months to get right.

I think the code in libpng to decompress iCCP safely has actually
taken several years, although we also validate the structure of the
ICC profile (uncompressed) to ensure it doesn't have the potential to
cause simple app crashes.

The most serious CVE level bug I remember was the one whereby
decompression of the profile allowed a DoS attack either by running
out of memory or via the "realloc" exploit which allowed an attacker
to slow decoding of a single PNG to minutes.  This is why Glenn had to
add the original profile length of the zXIf proposal, and why it was
there from the start in the cOMp proposal.

Doing this code *inside* the library is safe, the problem is still
that this is not going to happen; libpng, the most commonly used
library, is still stuck at CVE-only version 1.2 in some system
releases.  As I said originally Glenn was even against me putting
compressed iTXt license chunks in the current development version of
libpng (1.6) because of the lack of support in older versions!

-- 
John Bowler <[email protected]>
+1 (541) 450-9885
PO BOX 3151
KERBY OR 97531-3151
USA

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot