zlib double-free can lead to crash

RESOLVED FIXED

Status

()

Core
General
RESOLVED FIXED
16 years ago
7 years ago

People

(Reporter: dveditz, Assigned: dveditz)

Tracking

({crash})

Trunk
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: AOLTW+, AOLTWOK)

Attachments

(2 attachments)

(Assignee)

Description

16 years ago
Placeholder bug for patching the zlib double-free problem
(Assignee)

Comment 1

16 years ago
This apparently wouldn't be the only way to crash the browser using an image:
see bug 89595 and dupes where various png images crash us (but not in zlib).
Keywords: crash
Summary: zlib double-free → zlib double-free can lead to crash
(Assignee)

Comment 2

16 years ago
Created attachment 72157 [details] [diff] [review]
patch from Mark J Cox <mjc@redhat.com>

The patch blizzard forwarded from Mark Cox applies to the version of zlib in
the Mozilla tree (trunk and 0.9.4 branch)

r=dveditz
(Assignee)

Updated

16 years ago
Attachment #72157 - Flags: review+

Comment 3

16 years ago
Comment on attachment 72157 [details] [diff] [review]
patch from Mark J Cox <mjc@redhat.com>

a=asa (on behalf of drivers) for checkin to the 0.9.9 branch and the 1.0 trunk
Attachment #72157 - Flags: approval+
Comment on attachment 72157 [details] [diff] [review]
patch from Mark J Cox <mjc@redhat.com>

sr=shaver.

(This crash is a security issue, but all our others aren't? =) )
Attachment #72157 - Flags: superreview+
(Assignee)

Comment 5

16 years ago
There is supposed to be an undisclosed security exploit that can take advantage
of this, but since I don't know what it is I just put "crash" in the summary.
Netscape security folks (Jim Roskind, Mitch Stoltz) don't see how you can do
much with heap corruption, but it could be a PR issue to be able to say "we've
fixed it".
(Assignee)

Comment 6

16 years ago
Fix checked into 0.9.9 branch and the 1.0 trunk. Is this wanted/approved for 
check-in on the 0.9.4 branch?
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
I've just been reading about how to exploit heap corruption - it's harder, but
it can be done. Basically, it involves tricking free() into overwriting memory
at some arbitrary location. So I think this bug is likely to be exploitable.
Doesn't that require the attacker to control the value passed to free?  I've
diagnosed double-free/illegal-free bugs before by spotting allocator-trashing of
the address that would hold allocator metadata for the value provided, but I
can't understand how an attacker -- even one who can control the contents of the
buffer -- would be able to exploit a double-free.  And I've got the allocator
source right here!

Can you share your heap-corruption exploit information?  Given mozilla's
memory-management state, it may be better for us to defend against such attacks
at a common malloc-wrapper point, rather than fire-drilling on each one as we
find it.
I got it out of "Writing Secure Code," by Michael Howard, Microsoft Press. I
will post the example later if I have time. You may be right about improving the
allocator, and we should look into that. In the meantime, for this particular
bug, my point was simply that we should go ahead and fix it rather than sit
around trying to prove that the crash is not exploitable. This was mainly for
the benefit of Netscape management. This bug is fixed, so let's move the
discussion over into n.p.m.security, or another newsgroup of your choice.
Please make sure you wait until after the 11th please.
Created attachment 73051 [details]
The original bug report

I've attached the complete description of the bug here.

Comment 12

16 years ago
I just landed this on the AOLTW branch.
This bug is public now.  Can we open it up?

(Regarding double-free exploits: they are indeed possible, though not in the
simple |free(x); free(x);| case.  I haven't looked at the zlib code to see if
this can result in anything more significant than a crash, but in other code,
such as traceroute, is has been possible.  Agreed with Mitch, though: fix it
first, when it's easy and clean.)

Comment 14

16 years ago
Plussing for AOLTW
Whiteboard: AOLTW+
(Assignee)

Comment 15

16 years ago
We have shipped a fixed version, and the vulnerability is public. Opening bug
Group: security?

Comment 16

16 years ago
Verified on 2002-02-13-6.2.2 build on WinNT

Clciked on the http://bugzilla.mozilla.org/show_bug.cgi?id=89595 and then
clicked on the image link http://gcc.gnu.org/benchresults/aov.html, the browser
crashed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Updated

16 years ago
QA Contact: brendan → bsharma
(Assignee)

Comment 17

16 years ago
bug 89595 is a completely different bug. Try the image referenced in the 
attached bug report.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 18

16 years ago
Verified as mentioned by Dan:

Clicked on the "The original bug report"
Clicked on the http://bugzilla.gnome.org/show_bug.cgi?id=70594
Clicked on the http://bugzilla.gnome.org/showattachment.cgi?attach_id=6607

And the png image opens fine.
QA Contact: bsharma → brendan
Dave Barrowman has asked that we keep this bug confidential until we have
shipped a fix. The bug is public, but we should hold off on publishing the
technical discussion until our fix is out the door. I'm putting this back in the
security group for now. If anyone objects, send email to
security-group@mozilla.org; let's not argue about it here in the bug.
Group: security?
Group: security?

Comment 20

16 years ago
Added AOLTWOK in the Status Whiteboard.

Verified on 6.2.2 on WinNT and MacOSX
Whiteboard: AOLTW+ → AOLTW+, AOLTWOK

Updated

10 years ago
Component: XP Miscellany → General
QA Contact: brendan → general
You need to log in before you can comment on or make changes to this bug.