734317 - libpng: Confirmation of another heap-buffer overflow not affecting mozilla

Status: RESOLVED FIXED

(Firefox :: Untriaged, defect)

Description

[Huzaifa Sidhpurwala]

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.

Comment 1

[Al Billings [:abillings - ex-MoCo]]

Adding some folks from the other libpng issue to make sure this is seen and commented upon.

Comment 2

[Huzaifa Sidhpurwala]

Anything on this yet?

Comment 3

[Daniel Veditz [:dveditz]]

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".

Comment 4

[Huzaifa Sidhpurwala]

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.

Comment 5

[Glenn Randers-Pehrson]

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).

Comment 6

[Daniel Veditz [:dveditz]]

We all seem to agree Mozilla code is not affected.

Comment 7

[Glenn Randers-Pehrson]

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.