2.15 KB, patch
|Details | Diff | Splinter Review|
2.15 KB, patch
|Details | Diff | Splinter Review|
When trying to open this image, Mozilla crashes. It also happens in Mozilla1.7.13 and other branches, so I'm filing this as security sensitive, just to be sure. Talkback ID: MOZ_PNG_init_read_transf [mozilla/modules/libimg/png/pngrtran.c, line 816] MOZ_PNG_read_start_row [mozilla/modules/libimg/png/pngrutil.c, line 3156] MOZ_PNG_read_update_info [mozilla/modules/libimg/png/pngread.c, line 628] MOZ_PNG_push_have_info [mozilla/modules/libimg/png/pngpread.c, line 1710] MOZ_PNG_proc_some_data [mozilla/modules/libimg/png/pngpread.c, line 55] nsPipeInputStream::ReadSegments [mozilla/xpcom/io/nspipe3.cpp, line 766] nsPNGDecoder::WriteFrom [mozilla/modules/libpr0n/decoders/png/nspngdecoder.cpp, line 259] imgRequest::OnDataAvailable [mozilla/modules/libpr0n/src/imgrequest.cpp, line 903]
png_ptr->num_trans is 1 but png_ptr->trans is null, so dereferencing png_ptr->trans[i] crashes. How did we get in that state? If num_trans and trans can get out of sync there might be ways to get trans set to a non-null value. Are we trusting the image data without validation?
Also occurs on Linux.
Created attachment 259303 [details] [diff] [review] wip I think the bug is in png_handle_tRNS: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/modules/libimg/png/pngrutil.c&rev=3.13&root=/cvsroot&mark=1309,1318,1319,1321#1288 We set "png_ptr->num_trans" to 1 at line 1309 (ok), but then there is a CRC error detected on line 1318 and we return early - it is png_set_tRNS() at the end that allocates the 'trans' buffer. FYI, this patch makes us display some kind of fallback image that says we don't support APNG. I'm not sure if that's the expected result.
I also looked briefly at png_set_tRNS. It does not seem to handle OOM very well... http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/modules/libimg/png/pngset.c&rev=3.11&root=/cvsroot&mark=927,930,932,934,942,943,946#909 We should probably set num_trans=0 here and not set the FREE_TRNS flag and not set info_ptr->valid bit if OOM occurs.
Clamping num_trans to PNG_MAX_PALETTE_LENGTH in png_set_tRNS wouldn't hurt too...
It might be worth asking the libpng people since this is an external library?
Ah sorry, maybe this is basically what bug 373249 is about?
bug 373249 looks different, I don't think it's related to this bug.
-> Mats, I know nothing about this
Cannot figure out how to download the image. Firefox crashes, Seamonkey crashes and takes the windows display driver with it. Lynx and IE can't get past the "proceed" button.
Created attachment 263849 [details] [diff] [review] bugfix, MOZCHANGES, minimum system library 1.2.17 (checked in to trunk) The patch seems correct. Here is an updated patch that also updates MOZCHANGES and sets the minimum system libpng to 1.2.17 which will be released next week with the patch, and uses the bracketing style of libpng.
(In reply to comment #0) > When trying to open this image, Mozilla crashes. > It also happens in Mozilla1.7.13 and other branches, so I'm filing this as > security sensitive, just to be sure. The vulnerability has existed in libpng since version 0.90 so it will affect all versions of gecko, whether they use the system libpng or the embedded one.
Comment on attachment 263854 [details] [diff] [review] patch for 1.8 branch (checked in to branch) > dnl Set the version number of the libs included with mozilla > dnl ======================================================== > MOZJPEG=62 >-MOZPNG=10207 >+MOZPNG=10217 This doesn't seem right, fixing this bug does not take us to 1.2.17 *on the branches* which is lacking (most of) the changes from 1.2.7 to 1.2.16, right? Looks good otherwise, also for the 1.8.0 branch.
(In reply to comment #14) > This doesn't seem right, fixing this bug does not take us to 1.2.17 > *on the branches* which is lacking (most of) the changes from 1.2.7 > to 1.2.16, right? See discussion in bug #373249. Security-wise, the branch is at the same level as trunk, except for some additional tests for NULL pointers on the trunk. But this bug casts a new light on the situation. Unpatched system libraries through 1.2.16 are vulnerable to a simple attack via a PNG with a malformed tRNS chunk. We don't have a way of detecting whether the system library has been patched. Of course they are all unpatched now because we haven't released the patch yet (I've reported it to CERT but have not heard back from them).
Ok, that bug explains it, thanks.
Comment on attachment 263849 [details] [diff] [review] bugfix, MOZCHANGES, minimum system library 1.2.17 (checked in to trunk) Tor: r?
Comment on attachment 263854 [details] [diff] [review] patch for 1.8 branch (checked in to branch) tor: r for branch?
(In reply to comment #15) >(I've reported > it to CERT but have not heard back from them). Still no word from CERT. Silly me forgot they are paid to respond and therefore won't look at it until the next work day. We should probably coordinate the release of the mozilla patch with the libpng-1.2.17 release.
If this doesn't make 22.214.171.124/126.96.36.199 then the next planned release is 188.8.131.52 in July. Can this wait, or should we squeeze it into 184.108.40.206 ahead of any coordination (and not announce anything). What "new light" (comment 15) does this bug cast? It still looks like a null deref which we can live with. I guess the size of num_trans is under the control of the attacker, but there's at least one check that it's <= 256 which doesn't get an attacker into the heap on most OS's.
"new light" is as I said in comment #10, seamonkey crashes and takes my windows display with it. Throws my screen into "safe" mode. I doubt that an attacker could use it to break into a system or to elevate priveleges. This is probably only a Denial of Service problem. This is new because it can be caused by a malformed PNG image on a web site. The other NULL problems are only due to application programming errors, which gecko/libpr0n doesn't have. The erroneous num_trans can only be "1". I still haven't heard from CERT (guess they don't come in early on Mondays) but suspect they will ask for 45 days. I don't have a problem with releasing a change without anouncing why.
I just now heard from CERT: Thank you for the report, we are tracking this as VU#684664. We will follow up with our established contacts at libpng.
Comment on attachment 263849 [details] [diff] [review] bugfix, MOZCHANGES, minimum system library 1.2.17 (checked in to trunk) sr anyone?
(In reply to comment #3) > FYI, this patch makes us display some kind of fallback image > that says we don't support APNG. I'm not sure if that's the > expected result. Yes, I see that, too, with the patch and also with a MNG-supporting build that does not use libpng and is therefore not vulnerable. That is correct behaviour for the MNG-supporting build but I'm not sure why the patched one does not show the APNG animation. Here's a "pngcrush -fix -v" report: Reading IHDR chunk, length = 13. Reading PLTE chunk, length = 48. Reading tRNS chunk, length = 1. libpng warning: : CRC error Reading bKGD chunk, length = 1. Reading acTl chunk, length = 16. Reading IDAT chunk, length = 2386. Reading fcTl chunk, length = 25. Reading tIME chunk, length = 7. Reading fdAt chunk, length = 2554. Reading fcTl chunk, length = 25. Reading fdAt chunk, length = 2579. [etc] Hmmm, the chunk names are wrong (should end with L and T not l and t) so that explains why we see the fallback. It's proper behaviour.
I received a request to use CVE name CVE-2007-2445 for this issue
(In reply to comment #20) > If this doesn't make 220.127.116.11/18.104.22.168 then the next planned release is 22.214.171.124 > in July. When are 126.96.36.199/188.8.131.52 due out? I've spoken with CERT and they don't have a problem with a quick release, e.g., May 15th, with an announcement. I was planning to release libpng-1.2.17 on May 12 but it's no problem waiting until May 15 or so. CERT is pretty much leaving it up to us when to disclose/release.
Libpng-1.2.17, with the patch and a security advisory, will be released tomorrow, May 15th, at noon EST.
If anyone here has sr privileges, please do the superreviews.
Comment on attachment 263849 [details] [diff] [review] bugfix, MOZCHANGES, minimum system library 1.2.17 (checked in to trunk) sr=dveditz
Comment on attachment 263854 [details] [diff] [review] patch for 1.8 branch (checked in to branch) sr=dveditz
The libpng release is delayed from noon until 4:00 PM EST tomorrow, May 15.
Oops, EDT not EST.
Libpng-1.2.17 has been released.
Comment on attachment 263854 [details] [diff] [review] patch for 1.8 branch (checked in to branch) approved for 184.108.40.206 and 220.127.116.11, a=dveditz for release-drivers
fix landed on branches
fix checked into trunk.
verified fixed 18.104.22.168 using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124pre) Gecko/2007071216 BonEcho/126.96.36.199pre and Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:188.8.131.52pre) Gecko/2007071216 BonEcho/184.108.40.206pre also a mac build with this testcase - no crash on testcase - adding verified keyword
Someone please clear the security-sensitive flag.
also no crash with thunderbird 220.127.116.11 with thunderbrowse. Thunderbrowse mark this url as too long.
verified fixed 18.104.22.168 with Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:22.214.171.124pre) Gecko/20070822 Firefox/126.96.36.199pre - no crash on test url adding verified keyword
crash test landed http://hg.mozilla.org/mozilla-central/rev/90a53b9435a4