I am not sure if glenn already informed mozilla about this issue. (Most probably he already did and i am being paranoid). The following was fixed in libpng and in chrome as well: http://src.chromium.org/viewvc/chrome?view=rev&revision=125311 This is similar to the previous libpng which i had reported. Glenn provided the following explanation of why moz. would not have been affected by this: "Chunks that you know you will never use should be listed in a "png_set_keep_unknown_chunks()" call with the property PNG_HANDLE_CHUNK_NEVER as demonstrated in libpng's contrib/gregbook/readpng2.c, which will prevent the listed chunks from being processed. Mozilla uses this method to skip zTXt, iTXt, and other chunks that it doesn't use, and has consequently not been affected by most of the CVEs involving libpng in recent years. You can prevent DoS by large zTXt, etc., chunks by setting limits on the amount of expansion allowed. Mozilla, for example, sets a limit of 4MB on the maximum size of an iCCP chunk after decompression." Looking at the code, i seem to agree with the above. But since i am not an expert can someone with more knowledge please comment? Thanks.
Adding some folks from the other libpng issue to make sure this is seen and commented upon.
Anything on this yet?
We have this fix on trunk already, as part of the upgrade to libpng 1.5.9 in bug 648690: http://hg.mozilla.org/mozilla-central/annotate/5ec9524de1af/media/libpng/pngrutil.c#l343 Even in unfixed code we skip over the bug the first time png_inflate() is called from png_decrompress_chunk() because 0 is passed as output and output_size, and we'll only fall into this code on the second call to png_inflate() if the expanded size is < 4Mb as noted in comment 0. We should be able to close this one "worksforme" or "invalid".
Daniel, The Update to 1.5.9 is not applicable to ESR, that would mean ESR is still vulnerable, if you can call this as a vulnerability as such.
We have been using the png_set_keep_chunk() mechanism to ignore zTXt and iTXt chunks for quite a long time. The only compressed chunks we process are IDAT (which is decompressed by different code) and iCCP (which only calls png_inflate() once).
We all seem to agree Mozilla code is not affected.
The security flag on this bug can be cleared now. There is nothing here that isn't exposed in public CVEs and in the source for libpng-1.5.10.