Closed Bug 157202 Opened 22 years ago Closed 22 years ago

Exploitable (?) heap overrun in PNG

Categories

(Core :: Security, defect)

Product:
Core
Component:
Security
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: security-bugs, Assigned: pavlov)

References

Details

(Whiteboard: [adt1 rtm] [ETA 07/23])

Attachments

(4 files, 6 obsolete files)

change int16s to int32s
1.00 KB, patch
dougt
: review+
tor
: superreview+
chofmann
: approval+
Details | Diff | Splinter Review
This crashes on linux even after the proposed patch
592 bytes, image/png
Details
one patch for all the decoders
4.38 KB, patch
dougt
: review+
tor
: superreview+
asa
: approval+
Details | Diff | Splinter Review
limit size to (2^15)-1
1.35 KB, patch
dougt
: review+
tor
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
Subject:
exploitable heap corruption via PNG Alpha data
From:
zen-parse <zen-parse@gmx.net>
Date:
Sat, 13 Jul 2002 04:04:56 +1200 (NZST)

This problem allows execution of arbitrary code via Netscape 6.2.3.

Product: 			Netscape 6.x
Platform: 			Unix: x86 Linux
Operating system version: 	Redhat 7.0

exploitable heap corruption via PNG Alpha data 
I believe the fault lies somewhere around here:
http://lxr.mozilla.org/mozilla/source/gfx2/src/gfxImageFrame.cpp#326
A specially crafted invalid PNG, with reported dimensions of 65536x65536
such as and an 8-bit alpha channel (most likely, similar overflowing
values as well, such as 65531x32771 with 16-bit alpha, if that is
supported),can cause controllable heap corruption, overwriting (at least)
a pointer to a function pointer that allows arbitary code to be executed.

An example exploit for this is on:

http://crash.ihug.co.nz/~Sneuro/pngkiller2.tar.gz

The code is somewhat commented and explains what I believe is happening,
although it was written while offline, and so without access to the source
to verify the accuracy.

However, this is a DIFFERENT problem to the previously reported PNG
problem.
Adding keywords, this sounds quite serious. Could someone (pavlov?) confirm this
crash?
Keywords: adt1.0.1, mozilla1.0.1, nsbeta1
Whiteboard: [adt1 rtm]
Blocks: 143047
Severity: normal → major
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt1 rtm] → [adt1 rtm] [ETA Needed]
Target Milestone: --- → mozilla1.0.1
I wasn't seeing the crash on my solaris box, but I'll try it on a few other 
machines.  I am having trouble building the crash code due to missing libraries 
and headers.
From Georgi:

Bug 157202 Exploitable (?) heap overrun in PNG really seems exploitable.
I had problems running the programs (probably because they need a lot of
disk space).
But the supplied laa.png really crashes mozilla in a nasty way - writes 0x42 to
the stack.

Georgi
Also, does this cause a crash on Windows?
where did Georgi find laa.png?
Two problems at first glance:

  * nsImageGTK uses signed shorts to describe alpha data metrics.  Changing
    them in nsImageGTK.h to PRUInt32s should eliminate that problem.

  * mozilla doesn't sanity check the amount of memory requested for an image.
    The example file (laa.png) wants 65536*65536*4 bytes.

Along the lines of excessive memory use, I'm not aware that we have any limit
to the total amount of memory used by the image cache for a page.  A possible
DOS attack would be to create a page with a number of large dimension solid
block pngs (which compress into trivially small files).
Depends on: 101948
this should fix the overflow on linux.	the overflow doesn't occur on the other
platforms.
Stuart Parmenter: the file laa.png is in the tar pngkiller2.tar.gz
Removing adt1.0.1, until this has been reviewed and verified on the trunk. 

Who can review and supper review Pav's patch?
Keywords: adt1.0.1
Whiteboard: [adt1 rtm] [ETA Needed] → [adt1 rtm] [ETA 07/20]
dougt: can you r=?  tor: can you sr=?
Comment on attachment 91785 [details] [diff] [review]
change int16s to int32s

do we have any logic that depends on the size of these ?

if not and assuming that this is well tested, r=dougt
Attachment #91785 - Flags: review+
Comment on attachment 91785 [details] [diff] [review]
change int16s to int32s

sr=tor

There's some logic in the alpha compositing that will break down if
screen dimensions get bigger than 16 bits, but since the X protocol
will break first we're safe.
Attachment #91785 - Flags: superreview+
Pav - Looks like you have the reviews. Can you pls land this on the trunk
tonight, so that we can have it verified by bindu tomorrow? thanks!
Keywords: adt1.0.1
Comment on attachment 91785 [details] [diff] [review]
change int16s to int32s

a=chofmann for trunk/1.1b
Attachment #91785 - Flags: approval+
landed on trunk.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Bindu, can you verify this on the trunk?
I disagree with Comment #7 "the overflow doesn't occur on the other
platforms."
The file laa.png crashes moz1.0 on win2k.
Are you sure the fix in *gtk* also fixes win2k?
Attached png consumes even more memory and still crashes latest CVS build on at
least linux.
I think this bug should be reopened per my 2 previous comments.
Today's linux CVS build passes the crash with laa.png (the reporters testcase)
but if it  is modified a little mozilla still crashes with the attached to this
bug testcase.
http://bugzilla.mozilla.org/attachment.cgi?id=91955&action=view
As I mentioned in comment 6, the nsImageGTK change is only a small portion
of the problem.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
My testcase seems to abort() mozilla and doesn't seem exploitable on linux IMHO.
The problem is a signed/unsigned issue.

Verified on 2002-07-19-trunk build on Win 2K and Linux.

Try to open the laa.png in http://crash.ihug.co.nz/~Sneuro/pngkiller2.tar.gz
and the Win 2K and Linux crashes.
Blocks: 1.0.1

    
    

    
  


  

    
    

    
  


  

        Attachment #92019 -
        Attachment is obsolete: true

    
    

    
  


  

        Attachment #92018 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        fix ppm and xbm decoders as well (obsolete)
        — 
          — Splinter Review
      

    


  

    
  

        Attachment #92017 -
        Attachment is obsolete: true

        Attachment #92020 -
        Attachment is obsolete: true

        Attachment #92023 -
        Attachment is obsolete: true

    
    

    
  
ok, these 2 patches limit image sizes to 2^14 (16k) and will error out if 
images try to get bigger than that.
Keywords: patch

    
    

    
  
Comment on attachment 92024 [details] [diff] [review]
one patch for all the decoders

sr=tor

        Attachment #92024 -
        Flags: superreview+

    
    

    
  
Comment on attachment 92024 [details] [diff] [review]
one patch for all the decoders

r=dougt

        Attachment #92024 -
        Flags: review+

    
    

    
  
Comment on attachment 92021 [details] [diff] [review]
limit size of images to 2^14 x 2^14

r=saari

        Attachment #92021 -
        Flags: review+

    
    

    
  


  

        Attachment #92021 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 92030 [details] [diff] [review]
limit size to (2^15)-1

sr=tor

        Attachment #92030 -
        Flags: superreview+

    
    

    
  
Comment on attachment 92030 [details] [diff] [review]
limit size to (2^15)-1

r=dougt

        Attachment #92030 -
        Flags: review+

    
    

    
  
Comment on attachment 92024 [details] [diff] [review]
one patch for all the decoders

a=asa (on behalf of drivers) for checkin to 1.1

        Attachment #92024 -
        Flags: approval+

    
    

    
  
Comment on attachment 92030 [details] [diff] [review]
limit size to (2^15)-1

a=asa (on behalf of drivers) for checkin to 1.1

        Attachment #92030 -
        Flags: approval+

    
    

    
  
fixes checked in.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED

    
    

    
  
bsharma: bindu, can you verify this fix on the trunk? thanks!
Whiteboard: [adt1 rtm] [ETA 07/20] → [adt1 rtm] [ETA 07/23]

    
    

    
  
Verified on 2002-07-22-trunk on Win 2000.

The laa.png does not load and the error appears in the content window.

Status: RESOLVED → VERIFIED

    
    

    
  
Adding adt1.0.1 on behalf of the adt.  Please check this fix into the Mozilla
branch after getting branch approval from drivers.
Keywords: adt1.0.1 → adt1.0.1+

    
    

    
  
a=chofmann for 1.0.1.  add the fixed1.0.1 keyword after checking in on the branch.
Keywords: mozilla1.0.1 → mozilla1.0.1+

    
  
Keywords: fixed1.0.1

    
    

    
  
bsharma: bindu, can you verify this fix on the branch, then replace "fixed1.0.1"
with "verified1.0.1"? thanks!

    
    

    
  
Verified on 2002-07-25-branch on Win 2000.

The laa.png does not load and the error appears in the content window.


Keywords: fixed1.0.1 → verified1.0.1
Group: security?

    
    

    
  
*** Bug 101948 has been marked as a duplicate of this bug. ***

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