Closed
Bug 157989
Opened 22 years ago
Closed 22 years ago
Possible heap corruption with 0-width GIF
Categories
(Core :: Graphics: ImageLib, defect, P1)
Tracking
()
VERIFIED
FIXED
mozilla1.0.1
People
(Reporter: security-bugs, Assigned: pavlov)
References
Details
(Whiteboard: [adt1 RTM] [ETA 07/24])
Attachments
(2 files)
936 bytes,
patch
|
pavlov
:
review+
tor
:
superreview+
brendan
:
approval+
|
Details | Diff | Splinter Review |
104 bytes,
image/gif
|
Details |
Submitter name: zen-parse Submitter email address: zen-parse@gmx.net Acknowledgement checkbox: on Product: Netscape 6.x Operating system: Unix: x86 Linux OS version: redhat 7.0 Issue summary: a "0 width" GIF image: exploitable heap overwrite. Issue details: A specially formed gif image with width 0 can be used to overwrite 'chunk' information and other heap based information. By overwriting a function pointer with an address containing user supplied data, it is possible to execute arbitary code. http://lxr.mozilla.org/mozilla/source/modules/libimg/gifcom/gif.cpp#1274 down to line 1310 and then line 1351 and 1354 This form was submitted from http://help.netscape.com/forms/bug-security.html?cp=bbpctr with Opera/6.0 (Linux 2.2.19-7.0.16 i686; U) [en].
Reporter | ||
Comment 1•22 years ago
|
||
We need to know if this is really exploitable.
Whiteboard: [adt1 RTM]
Assignee | ||
Comment 2•22 years ago
|
||
Paper? Can you take a look at this?
Comment 3•22 years ago
|
||
Removing adt1.0.1 until there is a patch with reviews attached.
Comment 4•22 years ago
|
||
Firstly, gifcom is dead :) It's been moved to /modules/libpr0n/decoders/gif/ which still contains a lot of the old gifcom code. I talked it over with tor, and stopping the 0 width before the memory allocation seemed to be the best solution. And this is the patch. The memory overwrite actually happens later on during do_lzw, which first writes one byte, incrememnts the pointer, then checks whether it hit the end of the buffer. I looked into fixing the problem there, but it just caused problems in other areas (namely in BeginGIF(), which will never initialize mImageContainer if the width or height is 0.. which trickles down to assertion errors) I've also plugged the memory overwrite hole in do_lzw. In theory, the width check part of the patch should stop do_lzw from ever being called when the buffer is 0 in length, but it's better to check anyway.
Comment 5•22 years ago
|
||
This doesn't do anything malicious, however, it does crash Mozilla. I took a 14x14 GIF with one frame, and edited the image header and frame header so that it says 0x0.
Updated•22 years ago
|
Severity: normal → major
Priority: -- → P1
Target Milestone: --- → mozilla1.0.1
Comment 6•22 years ago
|
||
seems like we have a patch from Arron M. dan/mitch: can you review and super-review the patch, so we can try and get it landed asap. thanks!
Whiteboard: [adt1 RTM] [ETA Needed] → [adt1 RTM] [ETA 07/22]
Assignee | ||
Comment 7•22 years ago
|
||
Comment on attachment 91974 [details] [diff] [review] stop memory overwrite r=pavlov
Attachment #91974 -
Flags: review+
Comment on attachment 91974 [details] [diff] [review] stop memory overwrite sr=tor
Attachment #91974 -
Flags: superreview+
Comment 9•22 years ago
|
||
looks like we have the reviews. pav: are you in a position to land this patch for aaron m?
Keywords: adt1.0.1
Comment 10•22 years ago
|
||
who's in a position to apply this patch to the trunk, so we can get some bake time on this change?
Comment 11•22 years ago
|
||
Comment on attachment 91974 [details] [diff] [review] stop memory overwrite Mixed indentation (2 vs. 4 space), but that seems to pervade the file already. a=brendan@mozilla.org for 1.1beta trunk checkin. /be
Attachment #91974 -
Flags: approval+
Updated•22 years ago
|
Whiteboard: [adt1 RTM] [ETA 07/22] → [adt1 RTM] [ETA 07/24]
Comment 12•22 years ago
|
||
Adding adt1.0.1+ on behalf of the adt. Please get Drivers approval for the branch and check the fix into the branch.
Updated•22 years ago
|
Keywords: mozilla1.0.1 → mozilla1.0.1+
Comment 13•22 years ago
|
||
a=chofmann for 1.0.1. add the fixed1.0.1 keyword after getting this on the branch.
Assignee | ||
Comment 14•22 years ago
|
||
landed on trunk and branch.
Comment 15•22 years ago
|
||
thanks pav. tpreston: teri, can you verify this fix on the branch, then replace "fixed1.0.1" with "verified1.0.1"? thanks!
Comment 16•22 years ago
|
||
Verified fix checked into bonsai.mozilla.org and lxr.mozilla.org
Status: RESOLVED → VERIFIED
Keywords: fixed1.0.1 → verified1.0.1
Reporter | ||
Updated•22 years ago
|
Group: security?
You need to log in
before you can comment on or make changes to this bug.
Description
•