418900 - Update trunk to libpng-1.2.31

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Glenn Randers-Pehrson]

Libpng-1.2.25 has been released.  It fixes several NULL dereferences found in the library (not necessarily in Mozilla's embedded libpng) by Coverity.  It does not seem likely that any of these could be exploited remotely.  Libpng-1.2.25 does not introduce any new features.

Comment 1

[Glenn Randers-Pehrson]

Attachment: Update trunk to libpng-1.2.25

Comment 2

[Ryan VanderMeulen [:RyanVM]]

FYI, the attached patch appears to have Windows line endings.

Comment 3

[Glenn Randers-Pehrson]

Attachment: Update trunk to libpng-1.2.25 (v1)

Now with 1-byte line endings

Comment 4

[Ryan VanderMeulen [:RyanVM]]

Just wanted to mention that I've been running with this for the last week without any issues thus far.

Comment 5

[Glenn Randers-Pehrson]

Libpng-1.2.26 is in process but I don't believe it has any implications yet
for mozilla.  I guess it will be out around the end of March.

Comment 6

[Glenn Randers-Pehrson]

Attachment: update trunk to libpng-1.2.26

Libpng-1.2.26 has been released.

Comment 7

[Glenn Randers-Pehrson]

Attachment: Update trunk to libpng-1.2.26 (v1)

Resolves merge conflict due to checkin of patch from bug #420416

Comment 8

[Glenn Randers-Pehrson]

Libpng-1.2.27beta01 was released this morning (April 12) and libpng-1.2.27 is scheduled for release on or about April 26, 2008.

Comment 9

[Glenn Randers-Pehrson]

I recommend skipping 1.2.26 and waiting for libpng-1.2.27.  This is expected to resolve bug #428045

Comment 10

[Glenn Randers-Pehrson]

Attachment: update trunk to libpng-1.2.27beta01 (for testing)

This patch updates the trunk to libpng-1.2.27beta01.  I'll replace the patch with a new one and request r/sr when libpng-1.2.27 is released on or about April 26, 2008.  This should fix bug #428045.

Comment 11

[Glenn Randers-Pehrson]

Comment on attachment 315292 [details] [diff] [review]
update trunk to libpng-1.2.27beta01 (for testing)

Marking patch obsolete because the libpng group has decided to take another approach (simply issuing a warning without fixing the erroneous tRNS chunk data).  I'll post a new patch after the dust settles.

Comment 12

[Glenn Randers-Pehrson]

Attachment: Update trunk to libpng-1.2.27beta03 (for testing)

Here is a preview of libpng-1.2.27 which will be released around April 30.

Comment 13

[Glenn Randers-Pehrson]

Attachment: Update trunk to libpng-1.2.27

Libpng-1.2.27 has been released.

Comment 14

[Glenn Randers-Pehrson]

Libpng-1.2.28 has been released.  The libpng code is exactly the
same as in libpng-1.2.27; there is only a change in configuration
files that we do not use here, so there seems to be no need for
a new patch.

Comment 15

[Glenn Randers-Pehrson]

Attachment: Update trunk to libpng-1.2.29

Libpng-1.2.29 has been released.

Comment 16

[Andrew Smith]

Attachment: image that fails to decode

Assuming the 1.2.29 patch is the same as the 1.2.27 patch, it has a broken sequencial APNG reader.

Mostly it works, and the only thing I can think of that's special about this image is that the second frame is smaller than the first. Reading the second frame fails with:

...
        in png_read_row (row 71, pass 0)
        in png_combine_row
        in png_read_finish_row
        in png_read_row (row 72, pass 0)
        in png_combine_row
        in png_read_finish_row
        in png_read_row (row 73, pass 0)
libpng error: Extra compressed data

The sequencial reader isn't being used in Mozilla, but it probably shouldn't be included at all if it's broken.

I'm looking into it, but have very little spare time.

Comment 17

[Andrew Smith]

The problem goes away if the code in png_read_reset() is altered to be:

    png_ptr->flags &= ~PNG_FLAG_ROW_INIT;
    //png_read_start_row(png_ptr);

instead of the other way around.

Comment 18

[Glenn Randers-Pehrson]

Attachment: Update trunk to libpng-1.2.29 (v1)

Revised patch per Andrew's comment.

Comment 19

[Andrew Smith]

Sadly, it looks like with that the image in question works but several more others no longer do.

Comment 20

[Glenn Randers-Pehrson]

(In reply to comment #19)
> Sadly, it looks like with that the image in question works but several more
> others no longer do.

Is that with the progressive reader (libimg/libpr0n) or with the sequential
reader?  Is the nature of the error the same (wrong portions of the image
visible on subsequent frames)?

Comment 21

[Glenn Randers-Pehrson]

Attachment: Update trunk to libpng-1.2.31 (ignore whitespace changes)

Libpng-1.2.31 has been released.

Comment 22

[Glenn Randers-Pehrson]

Attachment: Update trunk to libpng-1.2.31

Comment 23

[Ryan VanderMeulen [:RyanVM]]

I'll try this out tonight and let you know how it goes.

Comment 24

[Ryan VanderMeulen [:RyanVM]]

   Creating library xul.lib and object xul.exp
png.lib(pngpread.obj) : error LNK2001: unresolved external symbol _png_handle_fdAT
png.lib(pngpread.obj) : error LNK2001: unresolved external symbol _png_handle_acTL
png.lib(pngpread.obj) : error LNK2001: unresolved external symbol _png_have_info
png.lib(pngpread.obj) : error LNK2001: unresolved external symbol _png_progressive_read_reset
png.lib(pngpread.obj) : error LNK2001: unresolved external symbol _png_read_reinit
png.lib(pngpread.obj) : error LNK2001: unresolved external symbol _png_handle_fcTL
png.lib(pngread.obj) : error LNK2001: unresolved external symbol _png_handle_fcTL
png.lib(pngpread.obj) : error LNK2001: unresolved external symbol _png_read_reset
png.lib(pngread.obj) : error LNK2001: unresolved external symbol _png_read_reset
png.lib(pngpread.obj) : error LNK2001: unresolved external symbol _png_ensure_sequence_number
png.lib(pngread.obj) : error LNK2001: unresolved external symbol _png_ensure_sequence_number
xul.dll : fatal error LNK1120: 8 unresolved externals

Comment 25

[Glenn Randers-Pehrson]

Attachment: Update trunk to libpng-1.2.31 (v1)

Changes "png_" prefix to "MOZ_PNG_" for exported APNG functions.

Comment 26

[Glenn Randers-Pehrson]

Attachment: Update trunk to libpng-1.2.31 (v2)

Prefix more exported APNG functions with PNG_APNG

Comment 27

[Glenn Randers-Pehrson]

(In reply to comment #26)

> Prefix more exported APNG functions with PNG_APNG

I meant to say, with MOZ_APNG

Comment 28

[Glenn Randers-Pehrson]

(In reply to comment #24)
>    Creating library xul.lib and object xul.exp
> png.lib(pngpread.obj) : error LNK2001: unresolved external symbol
> _png_handle_fdAT
>

This is curious, because the patch does not change anything with regard to the exported APNG functions, and they are treated exactly the same way as the similar "png_handle_*" functions in libpng proper.  Do you not see the same problem when trying to build the unpatched library from the trunk?  The only thing I can think of is some possible conflict with an existing system library, and the v1/v2 patches may help with that.

Comment 29

[Ryan VanderMeulen [:RyanVM]]

Well, v1 and v2 were giving me fits until I came upon a small typo in them :-)
-#define png_have_info                   MOZ_APNG_have info
+#define png_have_info                   MOZ_APNG_have_info

Sadly, I'm still getting the same errors. And yes, the current libpng in the tree works fine.
png.lib(pngpread.obj) : error LNK2001: unresolved external symbol _MOZ_APNG_handle_fdAT
png.lib(pngpread.obj) : error LNK2001: unresolved external symbol _MOZ_APNG_handle_acTL
png.lib(pngpread.obj) : error LNK2001: unresolved external symbol _MOZ_APNG_have_info
png.lib(pngpread.obj) : error LNK2001: unresolved external symbol _MOZ_APNG_prog_read_reset
png.lib(pngpread.obj) : error LNK2001: unresolved external symbol _MOZ_APNG_read_reinit
png.lib(pngpread.obj) : error LNK2001: unresolved external symbol _MOZ_APNG_handle_fcTL
png.lib(pngread.obj) : error LNK2001: unresolved external symbol _MOZ_APNG_handle_fcTL
png.lib(pngpread.obj) : error LNK2001: unresolved external symbol _MOZ_APNG_read_reset
png.lib(pngread.obj) : error LNK2001: unresolved external symbol _MOZ_APNG_read_reset
png.lib(pngpread.obj) : error LNK2001: unresolved external symbol _MOZ_APNG_ensure_seqno
png.lib(pngread.obj) : error LNK2001: unresolved external symbol _MOZ_APNG_ensure_seqno
xul.dll : fatal error LNK1120: 8 unresolved externals

Comment 30

[Glenn Randers-Pehrson]

Attachment: Update trunk to libpng-1.2.31 (v3)

Several APNG conditional blocks were mislocated in patches v1 and v2.

Comment 31

[Ryan VanderMeulen [:RyanVM]]

v3 compiles OK and the basic APNG demos seem to work OK. Also, as far as I can tell, attachment 320493 [details] seems to be working OK (assuming the desired behavior is to have a red square with a Firefox icon flashing periodically). However, the image linked from bug 433047 shows a column of pixels on the right side of the image while animating, which AFAICT isn't supposed to happen.

Comment 32

[Glenn Randers-Pehrson]

(In reply to comment #31)

> the image linked from bug 433047 shows a column of pixels on the right side of
> the image while animating, which AFAICT isn't supposed to happen.
> 

Doesn't that also happen with the unpatched libpng?

Comment 33

[Ryan VanderMeulen [:RyanVM]]

Correct, but I was under the impression from comment #2 in that bug that it would be fixed by the newer libpng. If that's not the case, we should probably at least remove the dependency on this bug.

Comment 34

[Glenn Randers-Pehrson]

Two one-byte overruns have been discovered in libpng-1.2.31 and are fixed in the latest beta (libpng-1.2.32beta01).  Neither of these are in parts of the code used by mozilla/firefox so there is no need to wait for libpng-1.2.32 on this account.

Comment 35

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 335150 [details] [diff] [review]
Update trunk to libpng-1.2.31 (v3)

stuart/tor, can you rubberstamp this?

Comment 36

[Ryan VanderMeulen [:RyanVM]]

Tryserver builds for those who may be interested:
https://build.mozilla.org/tryserver-builds/2008-09-07_06:[e-mail]-1220794773/

Comment 37

[Ryan VanderMeulen [:RyanVM]]

Still needs stuart's blessing.

Comment 38

[Joe Drew (not getting mail)]

Pushed in http://hg.mozilla.org/mozilla-central/rev/3bd94f1980a1

Comment 39

[ojab]

>Versions 1.2.30 and 1.2.31 of libpng can crash when reading images with multiple zTXt chunks; it is likely that this vulnerability could lead to a remote compromise in the case of a libpng-based browser visiting a hostile web site. This vulnerability has been assigned ID CVE-2008-3964 and is fixed in version 1.2.32, released 18 September 2008.  

libpng-1.2.33 is out.

Comment 40

[Glenn Randers-Pehrson]

We do not read the zTXt chunk and are immune to this vulnerability, whether we use the embedded libpng or the system libpng.