Re: CALL for DISCUSSION: eXIf 20170115

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