New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Email to this user bounced
Closed: Mar 2012
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Heap-buffer-overflow in wk_png_inflate

Reported by glen...@gmail.com, Feb 28 2012

Issue description

Chrome Version       : 17.0.963.56
OS Version: 
URLs (if applicable) :
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5:
  Firefox 4.x:
     IE 7/8/9:

What steps will reproduce the problem?
1.visit http://www.simplesystems.org/users/glennrp/libpng-crashers
2.visit each page
3.wait

What is the expected result? hang for a few seconds, then reject the chunk and display the image (the "original" bad.png won't fail because that was the subject of your recent bugfix, and the scal-related one probably won't fail unless you have disabled floating point support and enabled fixed point support in libpng.


What happens instead?
some will give the chrome "Oh, smap" page and others just hang with the throbber chasing its tail.

Please provide any additional information below. Attach a screenshot if
possible.

The PNG images contain compressed ancillary chunks that expand to 3 or 4 Gigabytes (in the file names, "3g" or "4g" indicates which.
The 3g ones are simply large, while the 4g ones may trigger a 32-bit integer overflow similar to the earlier bug with the iCCP chunk.

UserAgentString: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.56 Safari/535.11

These bugs have been publicly fixed recently in the latest libpng beta
distributions; we discovered them in the process of fixing the recent bug with iCCP that was revealed to the libpng group on February 15 (roughly simultaneous with your revealing it publicly).

Chunks that you know you will never use should be listed in a "png_set_keep_unknown_chunks()" call with the property PNG_HANDLE_CHUNK_NEVER as demonstrated in libpng's contrib/gregbook/readpng2.c, which will prevent the listed
chunks from being processed.  Mozilla uses this method to
skip zTXt, iTXt, and other chunks that it doesn't use, and
has consequently not been affected by most of the CVEs involving
libpng in recent years.

You can prevent DoS by large zTXt, etc., chunks by setting
limits on the amount of expansion allowed.  Mozilla, for
example, sets a limit of 4MB on the maximum size of an iCCP
chunk after decompression.  The method of setting the maximum
varies with libpng version, although if you are building a
special-purpose embedded libpng, you can just set PNG_USER_CHUNK_MALLOC_MAX to a number like 4000000.
 

Comment 1 by glen...@gmail.com, Feb 29 2012

New to this bug tracker, don't know how to set the Area and OS.  Should be WebKit (I think) and all OS.
Labels: Restrict-View-SecurityTeam
 Issue 116542  has been merged into this issue.
Labels: -OS-Linux -Area-Undefined -Type-Bug OS-All Area-WebKit Type-Security
Hi Glenn. Thanks for notifying us. I've tested each png that you link to on that page in Chrome 17.0.963.56 on Windows, but did not see any crashes. All of them do cause the page to stay in the "loading" phase, with the spinner going round and round indefinitely. However, they aren't using any CPU cycles or allocating large amounts of RAM and you can easily close the tabs, so I don't see any problem that would affect a user.

Can you tell me which files cause the renderer to crash ("Oh, snap!") for you and what OS-es you tested on? Also, do you see excessive CPU or memory usage?
Well, what do you know.... one second after I press "Save changes", all tabs crashed :)
I'll check this out in a debugger, brb.
More info from Glenn copied from the other bug:

The fix (to prevent integer overflow) is in libpng-1.2.48rc01:

diff -u libpng-1.2.47/pngrutil.c libpng-1.2.48rc01/pngrutil.c
--- libpng-1.2.47/pngrutil.c	2012-02-18 14:05:21.883080828 -0600
+++ libpng-1.2.48rc01/pngrutil.c	2012-03-02 07:32:05.355609901 -0600

@@ -247,8 +247,8 @@
       {
          if (output != 0 && output_size > count)
          {
-            int copy = output_size - count;
-            if (avail < copy) copy = avail;
+            png_size_t copy = output_size - count;
+            if ((png_size_t) avail < copy) copy = (png_size_t) avail;
             png_memcpy(output + count, png_ptr->zbuf, copy);
          }
          count += avail;

Of course all tabs crashed because they were hosted in the same renderer processes. After trying each png individually, I got these results:
 bug727401 -3g-iccp => OOM crash
 bug727401 -4g-iccp => Arbitrary write AV (this is probably a security issue)
 bug727401 -3g-ztxt => Loads successfully
 bug727401 -4g-ztxt => Loads successfully
 bug727401 -3g-itxt => Loads successfully
 bug727401 -4g-itxt => Loads successfully
 bug727401 -bad => Arbitrary write AV (this is probably a security issue)
scal_crc => Loads successfully

I'd upload them into ClusterFuzz, but it's very, very slow and I got to go now...
Owner: cevans@chromium.org
Status: Assigned
Thanks, SkyLined! I can take it from here.

@glennrp: thanks for sending this over, and I apologize that I handled the original libpng issue poorly.
Labels: SecSeverity-High SecImpacts-Stable Mstone-17
Labels: SecImpacts-Beta
Summary: Heap-buffer-overflow in wk_png_inflate
Detailed report: https://cluster-fuzz.appspot.com/testcase?key=24627336

Uploader: inferno@chromium.org

Crash Type: Heap-buffer-overflow READ 1
Crash Address: 0x7f9d4aaca07e
Crash State:
  - crash stack -
  wk_png_inflate
  wk_png_decompress_chunk
  - free stack -
  wk_png_push_save_buffer
  wk_png_push_read_chunk
  

Unminimized Testcase: https://cluster-fuzz.appspot.com/download/AMIfv95kDsN-TWAB0gB3qFZJ2T1keWjvL0DBzGj8MDJ3NOn-J676TO7zqEMSXZdAI7Ha0ScEz7NBcNhm9JNXRyE2bG8QgIFHdPwTcUR7Cp0mD86OQvBZQRbuBhLaIwaeo7AHD0SLQXSRQLYENjTwMATMhQLPY2Wulw
Just a fyi, this is a extremely flaky test on ClusterFuzz, so you wont see the necessary bits on regression, etc.
Project Member

Comment 14 by bugdroid1@chromium.org, Mar 7 2012

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=125311

------------------------------------------------------------------------
r125311 | cevans@chromium.org | Tue Mar 06 19:14:32 PST 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/third_party/libpng/README.chromium?r1=125311&r2=125310&pathrev=125311
 M http://src.chromium.org/viewvc/chrome/trunk/src/third_party/libpng/pngrutil.c?r1=125311&r2=125310&pathrev=125311

Pull follow-up tweak from upstream.

BUG= 116162 

Review URL: http://codereview.chromium.org/9546033
------------------------------------------------------------------------
Labels: -Restrict-View-SecurityTeam -Mstone-17 Restrict-View-SecurityNotify Mstone-18 Merge-Approved reward-topanel
Missed today's Beta; will merge for the next one.
Status: FixUnreleased
Labels: -reward-topanel
Do you guys intend to assign a CVE id to this issue?
Not yet, would you like me to do so?
Yes please, thanks
Labels: CVE-2011-3045
CVE-2011-3045

Comment 22 by glen...@gmail.com, Mar 8 2012

I have been reading the source and now understand that chrome always uses its own bundled libpng and never decodes zTXt or iTXt chunks, so please ignore the next to last paragraph of my original submission regarding the use of png_set_keep_unknown_chunks().  However we're still open to DoS by huge iCCP chunks; I'll open a separate bug about that.

Comment 23 by glen...@gmail.com, Mar 8 2012

libpng-1.2.48 was released today.  It contains the bugfix mentioned in comment #6.
Project Member

Comment 24 by bugdroid1@chromium.org, Mar 12 2012

Labels: merge-merged-1025
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=126193

------------------------------------------------------------------------
r126193 | cevans@chromium.org | Mon Mar 12 12:39:16 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/1025/src/third_party/libpng/pngrutil.c?r1=126193&r2=126192&pathrev=126193
 M http://src.chromium.org/viewvc/chrome/branches/1025/src/third_party/libpng/README.chromium?r1=126193&r2=126192&pathrev=126193

Merge 125311 - Pull follow-up tweak from upstream.

BUG= 116162 

Review URL: http://codereview.chromium.org/9546033

TBR=cevans@chromium.org
Review URL: https://chromiumcodereview.appspot.com/9689019
------------------------------------------------------------------------
Labels: -Merge-Approved Merge-Merged
Labels: -Mstone-18 Mstone-17
Project Member

Comment 27 by bugdroid1@chromium.org, Mar 20 2012

Labels: merge-merged-963
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=127742

------------------------------------------------------------------------
r127742 | cevans@chromium.org | Tue Mar 20 11:58:14 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/963/src/third_party/libpng/README.chromium?r1=127742&r2=127741&pathrev=127742
 M http://src.chromium.org/viewvc/chrome/branches/963/src/third_party/libpng/pngrutil.c?r1=127742&r2=127741&pathrev=127742

Merge 125311 - Pull follow-up tweak from upstream.

BUG= 116162 

Review URL: http://codereview.chromium.org/9546033

TBR=cevans@chromium.org
Review URL: https://chromiumcodereview.appspot.com/9768001
------------------------------------------------------------------------

Comment 28 by cdn@chromium.org, May 15 2012

Status: Fixed
Marking old security bugs Fixed..
Project Member

Comment 29 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 30 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-WebKit -Type-Security -SecSeverity-High -SecImpacts-Stable -Mstone-17 -SecImpacts-Beta Cr-Content Security-Impact-Stable Type-Bug-Security Security-Severity-High Security-Impact-Beta M-17
Project Member

Comment 31 by bugdroid1@chromium.org, Mar 13 2013

Labels: Restrict-View-EditIssue
Project Member

Comment 32 by bugdroid1@chromium.org, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Labels: -Restrict-View-SecurityNotify -Restrict-View-EditIssue
Project Member

Comment 34 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Severity-High Security_Severity-High
Project Member

Comment 35 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member

Comment 36 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Impact-Beta Security_Impact-Beta
Project Member

Comment 37 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 38 by sheriffbot@chromium.org, Jun 14 2016

Labels: -security_impact-beta
Labels: reward-topanel
Project Member

Comment 40 by sheriffbot@chromium.org, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 41 by sheriffbot@chromium.org, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: allpublic
Labels: -reward-topanel reward-NA
Labels: CVE_description-submitted
Project Member

Comment 45 by sheriffbot@chromium.org, Jul 29

Labels: -Pri-2 Pri-1

Sign in to add a comment