Last Comment Bug 727401 - (CVE-2011-3026) libpng: integer overflow leading to heap-buffer overflow
(CVE-2011-3026)
: libpng: integer overflow leading to heap-buffer overflow
Status: VERIFIED FIXED
[sg:critical][qa!]
: testcase, verified-aurora, verified-beta, verified1.9.2
Product: Core
Classification: Components
Component: ImageLib (show other bugs)
: 10 Branch
: All All
: -- critical (vote)
: mozilla13
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
jar:https://bugzilla.mozilla.org/atta...
Depends on:
Blocks: 727693
  Show dependency treegraph
 
Reported: 2012-02-15 02:22 PST by Huzaifa Sidhpurwala
Modified: 2012-10-23 07:54 PDT (History)
43 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
verified
+
verified
+
verified
+
verified
10+
verified
.27+
.27-fixed


Attachments
Mozilla patch (1.49 KB, patch)
2012-02-15 06:11 PST, Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg]
joe: review+
dveditz: superreview+
akeybl: approval‑mozilla‑aurora+
akeybl: approval‑mozilla‑beta+
akeybl: approval‑mozilla‑release+
Details | Diff | Splinter Review
testcase from Chrome (6.86 KB, application/zip)
2012-02-15 14:15 PST, Daniel Veditz [:dveditz]
no flags Details

Description Huzaifa Sidhpurwala 2012-02-15 02:22:32 PST
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0
Build ID: 20120131115133

Steps to reproduce:

This bug was filed in the chromium bugzilla, i think moz. uses embedded libpng and may be affected as well:

VULNERABILITY DETAILS
Some code from png_decompress_chunk:

      png_size_t expanded_size = png_inflate(png_ptr,
                (png_bytep)(png_ptr->chunkdata + prefix_size),
                chunklength - prefix_size,
                0/*output*/, 0/*output size*/);

      /* some code removed */

      png_charp text = png_malloc_warn(png_ptr,
                        prefix_size + expanded_size + 1);

      /* some code removed */

      png_memcpy(text, png_ptr->chunkdata, prefix_size);

Here expanded_size returned by png_inflate can be arbitrarily large. This is
because png_inflate decompresses data in small chunks and throws them away if
output argument is 0.

Therefore prefix_size + expanded_size can overflow png_size_t (32 bits on my machine) which leads to faulty malloc and heap-buffer-overflow. Bytes at chunkdata and prefix_size are attacker-controlled.
Comment 1 Huzaifa Sidhpurwala 2012-02-15 02:23:26 PST
There is a reproducer as well, which hangs my firefox 10 install. You will need to ask the chromium folks for the repro though
Comment 3 Huzaifa Sidhpurwala 2012-02-15 02:35:38 PST
Also from the chromium bug
==========================

Ok, just a note on the actual libpng fix: the bug is fairly interesting because it is slightly different on 32-bit vs. 64-bit.

32-bit: straight integer overflow in addition.
64-bit: the types in the addition are actually 64-bit so no overflow there. HOWEVER, the internal malloc()-like function called is actually takes a 32-bit type for "size" so there is truncation! Doh!

I believe there's also an additional integer overflow in the loop that spins to calculate the overall length of the decompressed data. Seems harmless though, as this will simply result in a smaller buffer allocation for the actual decompress, which in turn will truncate the decompressed data rather than causing a corruption. So I left that alone.
Comment 4 Jesse Ruderman 2012-02-15 04:06:58 PST
> + if (prefix_size + expanded_size > prefix_size &&

Are we sure this check won't get optimized away? http://stackoverflow.com/a/6822698
Comment 5 Mike Hommey [:glandium] 2012-02-15 04:11:18 PST
(In reply to Jesse Ruderman from comment #4)
> > + if (prefix_size + expanded_size > prefix_size &&
> 
> Are we sure this check won't get optimized away?
> http://stackoverflow.com/a/6822698

Both prefix_size and expanded_size are unsigned, so that shouldn't be optimized away.
Comment 6 Jesse Ruderman 2012-02-15 04:12:52 PST
http://codereview.chromium.org/9363013
Comment 7 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2012-02-15 06:11:58 PST
Created attachment 597381 [details] [diff] [review]
Mozilla patch

This is a Mozilla patch which is a straight import of the Chromium patch. Try results pending: https://tbpl.mozilla.org/?tree=Try&rev=b3f1087ff17d
Comment 8 Joe Drew (not getting mail) 2012-02-15 06:41:14 PST
+Glenn, libpng maintainer.
Comment 9 Al Billings [:abillings] 2012-02-15 10:16:21 PST
Can we get a testcase?
Comment 10 Christian Holler (:decoder) 2012-02-15 10:21:29 PST
CCing Chris Evans: can we get the testcase for this bug from Google?
Comment 11 Daniel Veditz [:dveditz] 2012-02-15 14:15:04 PST
Created attachment 597556 [details]
testcase from Chrome
Comment 12 Daniel Veditz [:dveditz] 2012-02-15 14:19:13 PST
crash [@ MOZ_PNG_decomp_chunk ] in 1.9.2
bp-c6974b0f-8de5-435a-8cf2-09c552120215
Comment 13 Al Billings [:abillings] 2012-02-15 14:51:43 PST
bp-e9b8e461-40d0-4945-9017-b91692120215 for 10.0.1
Comment 14 Smokey Ardisson (offline for a while; not following bugs - do not email) 2012-02-15 15:04:42 PST
(In reply to Daniel Veditz from comment #12)
> crash [@ MOZ_PNG_decomp_chunk ] in 1.9.2
> bp-c6974b0f-8de5-435a-8cf2-09c552120215

There's some context (and weird code style) differences due to the older libpng on 1.9.2, but otherwise applying the changes in attachment 597381 [details] [diff] [review]/comment 7 builds and fixes the crash for me. (There's still a little period of beachballing before loading "finishes", but no crash, and the browser recovers once loading is "done".)
Comment 15 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-02-15 15:41:59 PST
Interesting that I get the following crash by just having the testcase file listed in the Open File dialog on Linux64: 
6ec77c0e-810b-470c-a6ef-a0af92120215

With the try build, it takes longer for the crash to happen. It also causes my file browser (Thunar) to crash. I'm guessing this bug is more wide-spread than just web browsers.

I guess I should file a bug with Fedora.
Comment 16 Martin Stránský 2012-02-15 15:47:10 PST
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #15)
> Interesting that I get the following crash by just having the testcase file
> listed in the Open File dialog on Linux64: 
> 6ec77c0e-810b-470c-a6ef-a0af92120215

The crash may come from system libpng, gtk widget (the Open File dialog) uses libpng to generate image previews.
Comment 17 Jeff Walden [:Waldo] (remove +bmo to email) 2012-02-15 15:50:55 PST
libpng gets used by ~everything, so it's not too surprising your file browser would crash.  libpng's ubiquity is well known enough that I doubt you need do anything (plus it doesn't hurt that there are Red Hat developers clearly aware of and involved in this issue).
Comment 18 juan becerra [:juanb] 2012-02-15 16:04:27 PST
I've checked that 10.0.1 and the nightly before the fix crash on XP. The try builds do not crash. I've also been playing with a couple of pgn test suites you can find online, and I haven't seen any problems with the try builds.
Comment 19 Brendan Eich [:brendan] 2012-02-15 16:06:10 PST
Cc'ing bhackett to ask whether sixgill would have caught this.

/be
Comment 20 Christian Holler (:decoder) 2012-02-15 16:09:43 PST
(In reply to Brendan Eich [:brendan] from comment #19)
> Cc'ing bhackett to ask whether sixgill would have caught this.
> 
> /be

Good idea Brendan, I'll also check if the Clang Static Analysis we recently started to use saw this.
Comment 21 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-02-15 16:11:51 PST
(In reply to Martin Stránský from comment #16)
> (In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #15) 
> The crash may come from system libpng, gtk widget (the Open File dialog)
> uses libpng to generate image previews.

Not sure -- I filed a bug in Fedora::Thunar reporting the issue.
https://bugzilla.redhat.com/show_bug.cgi?id=791030

Unfortunately I don't have privileges to take the necessary security precautions so I did my best to limit the initial info I posted. Feel free to comment on that bug if you can/want.

On a side note, this makes it impossible for me to test/verify this fix on Linux 64-bit.
Comment 22 Brian Hackett (:bhackett) 2012-02-15 16:13:14 PST
(In reply to Brendan Eich [:brendan] from comment #19)
> Cc'ing bhackett to ask whether sixgill would have caught this.
> 
> /be

No, sixgill just looks for straight up buffer overflows that do not involve any integer overflow.
Comment 23 Daniel Veditz [:dveditz] 2012-02-15 16:20:50 PST
Comment on attachment 597381 [details] [diff] [review]
Mozilla patch

sr=dveditz

I'm not exactly a libpng peer so I'll use sr= rather than r=, this is exactly the patch used by Chrome and in upstream linux distros.
Comment 24 Aaron Train [:aaronmt] 2012-02-15 16:38:13 PST
Android

bp-21b6ae00-56f7-493f-b0fd-7e8232120216
Comment 25 Joe Drew (not getting mail) 2012-02-15 17:08:43 PST
Comment on attachment 597381 [details] [diff] [review]
Mozilla patch

r=joe
Comment 26 Alex Keybl [:akeybl] 2012-02-15 17:12:37 PST
A quick note for whoever lands these fixes. Please make sure to land on tip for mozilla-beta (QA halted testing of Beta 3 so we can take newer changes) and GECKO1001_2012020805_RELBRANCH for mozilla-esr10. Thanks!
Comment 27 Alex Keybl [:akeybl] 2012-02-15 17:13:22 PST
Comment on attachment 597381 [details] [diff] [review]
Mozilla patch

[Triage Comment]
Please land on all branches (including esr10). Approved.
Comment 29 Nick Thomas [:nthomas] 2012-02-15 19:43:00 PST
Landed in ESR on GECKO1001_2012020805_RELBRANCH and default. Here's the relbranch:
http://hg.mozilla.org/releases/mozilla-esr10/rev/cc9013d9ffc1
Comment 30 Daniel Veditz [:dveditz] 2012-02-15 19:44:11 PST
https://hg.mozilla.org/mozilla-central/rev/592c27677267
Comment 31 Huzaifa Sidhpurwala 2012-02-15 19:48:54 PST
What about 1.9.2 ?
Comment 32 Daniel Veditz [:dveditz] 2012-02-15 20:31:25 PST
https://hg.mozilla.org/releases/mozilla-1.9.2/rev/fd6d19a5ae84

We don't have the right status values yet so I'll leave 1.9.2 unset for now and fix them in the morning.
Comment 33 Daniel Veditz [:dveditz] 2012-02-15 20:33:36 PST
The 1.9.2 patch didn't quite fix this for me in a debug build. It stayed running longer but eventually crashed with the same stack. Maybe I'm hitting an unrelated OOM issue.
Comment 34 Alex Keybl [:akeybl] 2012-02-15 22:32:18 PST
I just tested ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-1.9.2-macosx-debug/1329366409/ because it was the first OS X 1.9.2 build available.

1) File > Open File...
2) select bad.png and open it
3) Hang, beachball, then the browser is responsive and the text file:///Users/akeybl/Downloads/bad.png is displayed

Sounds like that's the expected behavior (ie success).
Comment 35 Alex Keybl [:akeybl] 2012-02-15 22:39:18 PST
Same behavior for ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-1.9.2-macosx/1329366409/. I'll go-to-build once I see if Dan has any different behavior on his machine (for whatever reason).
Comment 36 Huzaifa Sidhpurwala 2012-02-15 23:45:00 PST
(In reply to Alex Keybl [:akeybl] from comment #34)
> I just tested
> ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-1.9.2-
> macosx-debug/1329366409/ because it was the first OS X 1.9.2 build available.
> 
> 1) File > Open File...
> 2) select bad.png and open it
> 3) Hang, beachball, then the browser is responsive and the text
> file:///Users/akeybl/Downloads/bad.png is displayed
> 
> Sounds like that's the expected behavior (ie success).

Are we talking about unpatched firefox?. I can get the same behaviour on ff10.0
Comment 37 Huzaifa Sidhpurwala 2012-02-15 23:53:24 PST
(In reply to Huzaifa Sidhpurwala from comment #36)
> Are we talking about unpatched firefox?. I can get the same behaviour on
> ff10.0

Note: this is ff10 on 64 bit, so no crash is expected
Comment 38 Joe Drew (not getting mail) 2012-02-16 05:46:31 PST
Comment 34 implies this is OK on 1.9.2 now. Is that the case?
Comment 39 Alex Keybl [:akeybl] 2012-02-16 10:23:11 PST
(In reply to Joe Drew (:JOEDREW!) from comment #38)
> Comment 34 implies this is OK on 1.9.2 now. Is that the case?

Yep all good when built off of the 1.9.2 branch. We went to build last night.
Comment 40 Marcia Knous [:marcia - use ni] 2012-02-16 11:33:05 PST
Verified fixed using Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2. I verified the fix by loading the testcase and checking 10.0.1 first in this XP VM where it crashed, and then 10.0.2 I get a beachball but no crash is generated.

Some other QA team members are checking Mac and Linux but I will spot check as well.
Comment 41 Aaron Train [:aaronmt] 2012-02-16 11:57:42 PST
Likewise, verified fixed on Android via attached testcase: 

Samsung Galaxy Nexus (Android 4.0.2), HTC Desire HD (Android 2.3), Galaxy Tab 10.1 (Android 3.1) 

10.0.2, build candidate #1
Mozilla/5.0 (Android; Linux armv7l; rv:10.0.2) Gecko/20120215 Firefox/10.0.2 Fennec/10.0.2

11.0 Beta 3, build candidate #2
Mozilla/5.0 (Android; Tablet; rv:11.0) Gecko/11.0 Firefox/11.0 Fennec/11.0
Comment 42 Aaron Train [:aaronmt] 2012-02-16 12:07:20 PST
Also verified fixed on Android via attached testcase on same devices on Nightly/Aurora:

Mozilla/5.0 (Android; Mobile; rv:12.0a2) Gecko/12.0a2 Firefox/12.0a2
Mozilla/5.0 (Android; Mobile; rv:13.0a1) Gecko/13.0a1 Firefox/13.0a1
Comment 43 Marcia Knous [:marcia - use ni] 2012-02-16 12:30:56 PST
For 10.0.2:

Verified fixed using Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20100101 Firefox/10.0.2

For 11.0.b3:
Verified fixed from this directory: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/11.0b3-candidates/build2/. On Mac I verified in 32 bit mode so I could verify that I was not crashing with the patched build.

Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20100101 Firefox/11.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20100101 Firefox/11.0
Comment 44 Daniel Veditz [:dveditz] 2012-02-16 13:00:03 PST
(In reply to Joe Drew (:JOEDREW!) from comment #38)
> Comment 34 implies this is OK on 1.9.2 now. Is that the case?

Yes. My problem in comment 33 was maybe a build/dependency issue. Confirmed fixed.
Comment 45 Glenn Randers-Pehrson 2012-02-16 13:02:57 PST
The CVE is CVE-2011-3026
Comment 46 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-02-16 13:33:11 PST
Verified Fixed: 
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Comment 47 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-02-16 13:41:46 PST
Verified Fixed:
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0
Comment 48 Marcia Knous [:marcia - use ni] 2012-02-16 14:09:14 PST
Verified fixed on 3.6.27:

*Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.27) Gecko/20120216 Firefox/3.6.27
*Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.27) Gecko/20120216 Firefox/3.6.27
*Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.27) Gecko/20120216 Firefox/3.6.27
*Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.2.27) Gecko/20120216 Firefox/3.6.27
Comment 49 Glenn Randers-Pehrson 2012-02-16 14:20:56 PST
(In reply to Joe Drew (:JOEDREW!) from comment #8)
> +Glenn, libpng maintainer.

Thanks.  The libpng group did not hear about this bug until today.
Comment 50 Cameron Dawson [:camd] 2012-02-16 14:30:34 PST
Verified fixed on 10.0.2ESR:

* Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
* Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
* Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
* Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Comment 51 Geo Mealer [:geo] -- This account is inactive after 2015-07-07 2012-02-16 14:54:31 PST
Verified fixed on 3.6.27 Ubuntu 11.10 x32 and x64:

*Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Firefox/3.6.27
*Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.27) Gecko/20120216 Firefox/3.6.27
Comment 52 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-02-16 14:59:38 PST
Verified fixed on Firefox 13.0a1 2012-02-16.

Mozilla/5.0 (Windows; U; Windows NT 6.1; rv:13.0a1) Gecko/20120216 Firefox/13.0a1
Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:13.0a1) Gecko/20120216 Firefox/13.0a1
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0a1) Gecko/20120216 Firefox/13.0a1
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0a1) Gecko/20120216 Firefox/13.0a1
Mozilla/5.0 (X11; Linux x86_64; rv:13.0a1) Gecko/20120216 Firefox/13.0a1
Mozilla/5.0 (X11; Linux i686; rv:13.0a1) Gecko/20120216 Firefox/13.0a1
Comment 53 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-02-16 15:07:52 PST
Verified fixed on Firefox 12.0a2 2012-02-16.

Mozilla/5.0 (Windows; U; Windows NT 6.1; rv:12.0a2) Gecko/20120216 Firefox/12.0a2
Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:12.0a2) Gecko/20120216 Firefox/12.0a2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0a2) Gecko/20120216 Firefox/12.0a2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0a2) Gecko/20120216 Firefox/12.0a2
Mozilla/5.0 (X11; Linux x86_64; rv:12.0a2) Gecko/20120216 Firefox/12.0a2
Mozilla/5.0 (X11; Linux i686; rv:12.0a2) Gecko/20120216 Firefox/12.0a2
Comment 55 Al Billings [:abillings] 2012-03-15 13:54:00 PDT
Unhiding.

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