Re: CALL for DISCUSSION: eXIf 20170115

Back to the drawing board for zxIf.  It needs an "uncompressed length" byte
at the beginning.

I'll update the proposal accordingly, but won't bring zxIf up for a vote in
the near future.  Meanwhile we can proceed with the uncompressed eXIf vote
next week.  I'll continue to work on zxIf as a private
ImageMagick/GraphicsMagick chunk, to replace the existing
hex-encoded-Exif-in-zTXt chunk that we've been using for a decade.

Glenn

Glenn

On Fri, Jan 27, 2017 at 9:47 PM, John Bowler <
[email protected]> wrote:

> On Fri, Jan 27, 2017 at 7:11 PM, Glenn Randers-Pehrson
> <[email protected]> wrote:
> > I don't see any problem with it since we have access to the entire
> > buffer.
>
> There is no problem with it; I'm just saying that most programmers
> given the problem would not come up with that solution.  After all,
> the original libpng code used the "realloc" solution which sucks on
> every level (it's as memory-bad as the linked list but with added
> compute overhead.)
>
> This *IS* a security issue; my original (double decompress) suggestion
> was motivated by a fairly directed attack against the same issue in
> the iCCP chunk, but the issues in iCCP are almost trivial to fix (so
> far as I am concerned) because iCCP starts with a four-byte profile
> length in the compressed data.  (Also I had learned in the past that
> doing things twice correctly is invariably better than doing them fast
> once badly [also, Perot].)
>
> The same issue exists in iTXt, which has the undesirable property from
> the attackers viewpoint that it is not widely supported and the
> payload doesn't contain any bytes >=0xF5 and no 0 bytes (so no code
> there.)
>
> zTXt is somewhat more exploitable, but not much; like iTXt it outlaws
> 0 but it doesn't outlaw anything else.  That said the 0 byte is
> normally essential in computer code.
>
> Neither exploit is available any more in recent libpng versions; they
> do the double decode loop and so even though they don't properly check
> the data they are not vulnerable to any of the multifarious attacks.
>
> The proposed zXIf chunk has all the payload advantages of iCCP (any
> byte allowed; even if the TIFF format is completely checked unknown
> tags are valid as are spaces in the data.)  It does not have the nice
> iCCP characteristic of a known length and a single, verifiable, tag
> table (multiple IFDs in TIFF,  no length).
>
> This is a problem unique to PNG; other file formats do not compress
> data they do not define.  It's a problem a skilled programmer can
> avoid, though quite frankly the skills involved seem to be beyond most
> programmers and not, in themselves, readily marketable.  Therein lies
> the problem; expecting a random application programmer to get-it-right
> is not reasonable.  Sorry.  That's the world we live in.
>
> --
> 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
> _______________________________________________
> png-mng-misc mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/png-mng-misc
>

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

_______________________________________________
png-mng-misc mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/png-mng-misc