727401 - (CVE-2011-3026) libpng: integer overflow leading to heap-buffer overflow

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Huzaifa Sidhpurwala]

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]

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 2

[Huzaifa Sidhpurwala]

Chromium patch
==============

http://src.chromium.org/viewvc/chrome/branches/963/src/third_party/libpng/pngrutil.c?r1=121492&r2=121491&pathrev=121492

Comment 3

[Huzaifa Sidhpurwala]

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]

> + 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]]

(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]

http://codereview.chromium.org/9363013

Comment 7

[Benjamin Smedberg]

Attachment: 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)]

+Glenn, libpng maintainer.

Comment 9

[Al Billings [:abillings - ex-MoCo]]

Can we get a testcase?

Comment 10

[Christian Holler (:decoder)]

CCing Chris Evans: can we get the testcase for this bug from Google?

Comment 11

[Daniel Veditz [:dveditz]]

Attachment: testcase from Chrome

Comment 12

[Daniel Veditz [:dveditz]]

crash [@ MOZ_PNG_decomp_chunk ] in 1.9.2
bp-c6974b0f-8de5-435a-8cf2-09c552120215

Comment 13

[Al Billings [:abillings - ex-MoCo]]

bp-e9b8e461-40d0-4945-9017-b91692120215 for 10.0.1

Comment 14

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(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

[u279076]

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ý [:stransky] (ni? me)]

(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]]

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]]

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]]

Cc'ing bhackett to ask whether sixgill would have caught this.

/be

Comment 20

[Christian Holler (:decoder)]

(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

[u279076]

(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 [Laid off!]]

(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]]

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]]

Android

bp-21b6ae00-56f7-493f-b0fd-7e8232120216

Comment 25

[Joe Drew (not getting mail)]

Comment on attachment 597381 [details] [diff] [review]
Mozilla patch

r=joe

Comment 26

[Alex Keybl [:akeybl]]

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]]

Comment on attachment 597381 [details] [diff] [review]
Mozilla patch

[Triage Comment]
Please land on all branches (including esr10). Approved.

Comment 28

[Daniel Veditz [:dveditz]]

http://hg.mozilla.org/releases/mozilla-beta/rev/f21c6aa0f8c2
http://hg.mozilla.org/releases/mozilla-release/rev/bd611a3115b0
http://hg.mozilla.org/releases/mozilla-aurora/rev/c6fcc091279c

Comment 29

[Nick Thomas [:nthomas] (UTC+12)]

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]]

https://hg.mozilla.org/mozilla-central/rev/592c27677267

Comment 31

[Huzaifa Sidhpurwala]

What about 1.9.2 ?

Comment 32

[Daniel Veditz [:dveditz]]

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]]

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]]

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]]

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]

(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]

(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)]

Comment 34 implies this is OK on 1.9.2 now. Is that the case?

Comment 39

[Alex Keybl [:akeybl]]

(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]]

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]]

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]]

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]]

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]]

(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]

The CVE is CVE-2011-3026

Comment 46

[u279076]

Verified Fixed: 
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2

Comment 47

[u279076]

Verified Fixed:
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0

Comment 48

[Marcia Knous [:marcia]]

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]

(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]]

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]

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

[u279076]

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

[u279076]

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 - ex-MoCo]]

Unhiding.