Closed Bug 727401 (CVE-2011-3026) Opened 12 years ago Closed 12 years ago

libpng: integer overflow leading to heap-buffer overflow

Categories

(Core :: Graphics: ImageLib, defect)

10 Branch
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla13
Tracking Status
firefox10 --- verified
firefox11 + verified
firefox12 + verified
firefox13 + verified
firefox-esr10 10+ verified
blocking1.9.2 --- .27+
status1.9.2 --- .27-fixed

People

(Reporter: huzaifas, Unassigned)

References

()

Details

(4 keywords, Whiteboard: [sg:critical][qa!])

Crash Data

Attachments

(2 files)

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.
There is a reproducer as well, which hangs my firefox 10 install. You will need to ask the chromium folks for the repro though
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Severity: normal → critical
OS: Linux → All
Hardware: x86_64 → All
Summary: libpng: heap-buffer overflow → libpng: integer overflow leading to heap-buffer overflow
> + if (prefix_size + expanded_size > prefix_size &&

Are we sure this check won't get optimized away? http://stackoverflow.com/a/6822698
(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.
Attached patch Mozilla patch — — Splinter Review
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
+Glenn, libpng maintainer.
Component: Untriaged → ImageLib
Product: Firefox → Core
QA Contact: untriaged → imagelib
Can we get a testcase?
CCing Chris Evans: can we get the testcase for this bug from Google?
Attached file testcase from Chrome —
Whiteboard: [sg:critical]
crash [@ MOZ_PNG_decomp_chunk ] in 1.9.2
bp-c6974b0f-8de5-435a-8cf2-09c552120215
Crash Signature: [@ MOZ_PNG_decomp_chunk ]
(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".)
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.
(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.
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).
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.
Cc'ing bhackett to ask whether sixgill would have caught this.

/be
(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.
(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.
(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 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.
Attachment #597381 - Flags: superreview+
Attachment #597381 - Flags: approval-mozilla-release?
Attachment #597381 - Flags: approval-mozilla-beta?
Attachment #597381 - Flags: approval-mozilla-aurora?
Comment on attachment 597381 [details] [diff] [review]
Mozilla patch

r=joe
Attachment #597381 - Flags: review+
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 on attachment 597381 [details] [diff] [review]
Mozilla patch

[Triage Comment]
Please land on all branches (including esr10). Approved.
Attachment #597381 - Flags: approval-mozilla-release?
Attachment #597381 - Flags: approval-mozilla-release+
Attachment #597381 - Flags: approval-mozilla-beta?
Attachment #597381 - Flags: approval-mozilla-beta+
Attachment #597381 - Flags: approval-mozilla-aurora?
Attachment #597381 - Flags: approval-mozilla-aurora+
Blocks: 727693
Landed in ESR on GECKO1001_2012020805_RELBRANCH and default. Here's the relbranch:
http://hg.mozilla.org/releases/mozilla-esr10/rev/cc9013d9ffc1
https://hg.mozilla.org/mozilla-central/rev/592c27677267
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
What about 1.9.2 ?
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.
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.
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).
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).
(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
(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 34 implies this is OK on 1.9.2 now. Is that the case?
(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.
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.
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
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
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
(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.
The CVE is CVE-2011-3026
Verified Fixed: 
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Whiteboard: [sg:critical] → [sg:critical][qa+]
Verified Fixed:
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0
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
(In reply to Joe Drew (:JOEDREW!) from comment #8)
> +Glenn, libpng maintainer.

Thanks.  The libpng group did not hear about this bug until today.
Alias: CVE-2011-3026
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
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
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
Status: RESOLVED → VERIFIED
Keywords: verified1.9.2
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
Whiteboard: [sg:critical][qa+] → [sg:critical][qa!]
blocking1.9.2: ? → .27+
Attachment #597556 - Attachment is private: true
Unhiding.
Group: core-security
Attachment #597556 - Attachment is private: false
You need to log in before you can comment on or make changes to this bug.