tor: There isn't much change to the libpng code since 1.2.7, but there is some opportunity to save a few kbytes of footprint, especially in a situation where the PNG decoder is disabled but the PNG encoder is being used (I'm not sure that is the case with FF2 but can be true on the trunk). I'll post a revised mozpngconf.h that mahowi can merge with the patch.

Libpng-1.2.11 will be released in the next two weeks or so. The only code change, to eliminate a potential minor buffer-overflow, is in a part of pngrutil.c that is #ifdef'ed out of the embedded library.

(In reply to comment #25)
> I didn't think it was ever too late to fix security problems.
We're in release candidate stage for 1.8.1 - too late to fix security problems by doing a large update of an external library. If you have smaller security specific patches to the version of libpng on the branch we'd be interested in hearing about them.

Created attachment 239681[details][diff][review]
Fix libpng-1.2.7 security problems on 1.8 branch (checked in on branch)
Patch to fix only the security problems in libpng-1.2.7 and the libpr0n png decoder, on the 1.8 branch.

The vulnerabilities are announced at www.libpng.org, so we might want to push for FF2 rather than 1.8.1.1 (although as overruns go they don't sound so bad).
Glenn: can you be more specific about the sCAL write overrun? "rare" in real life images is not the same thing as "hard to do" when writing an exploit. Can a malicious image control the amount of overwrite here?

The sCAL bug cannot affect Firefox or any Gecko-based software. It only affects applications that deliberately write the sCAL chunk, i.e., that contain a call to png_write_sCAL() or png_write_sCAL_s(). libpr0n contains no such calls.
The buffer error message overrun is just two bytes and they are not under the
control of the image creator. The gamma_table overrun is just one byte being
read beyond an array and probably also not under the control of an image
creator. There aren't any known exploits for these.
On the other hand, it is simple to construct a PNG file with a malformed iCCP chunk that could crash Gecko when the system PNG library is employed. The fix
in nsPNGDecoder.cpp avoids that and similar problems by always handling iCCP
as an "unknown chunk to be ignored".

should probably leave this open for the mac bustage on the big patch -- we want to get apng in soon and on libpng 1.2.12. If anything, we should have probably filed another bug for the security patch. Oh well, too late now.

When I try to build with the bigger patch on the mac I end up getting:
/usr/bin/ld: Undefined symbols:
_MOZ_PNG_mmx_support
_MOZ_PNG_combine_row
_MOZ_PNG_do_read_int
_MOZ_PNG_read_filt_row
collect2: ld returned 1 exit status

To avoid the x86_64 problem, we could put in mozlibpngconf.h
#define PNG_NO_MMX_CODE
Doing it conditionally (so as now to slow down regular x86 machines)
is more complicated. We address it in libpng-1.4.0 by doing a trial
compile of pnggccrd.c in the configure script and setting the #define
if it fails.

To avoid the x86_64 problem, we could put in mozlibpngconf.h
#define PNG_NO_MMX_CODE
Doing it conditionally (so as not to slow down regular x86 machines)
is more complicated. We address it in libpng-1.4.0 by doing a trial
compile of pnggccrd.c in the configure script and setting the #define
if it fails.

This patch didn't change the minimum required system libpng in configure (for those who use -with-system-libpng) to match what was put in the tree, but it probably should. (I might clean that up in bug 372878 if nobody else does first.)

Note

You need to
log in
before you can comment on or make changes to this bug.