126898 - zlib double-free can lead to crash

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Daniel Veditz [:dveditz]]

Placeholder bug for patching the zlib double-free problem

Comment 1

[Daniel Veditz [:dveditz]]

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).

Comment 2

[Daniel Veditz [:dveditz]]

Attachment: patch from Mark J Cox <[e-mail]>

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

Comment 3

[Asa Dotzler [:asa]]

Comment on attachment 72157 [details] [diff] [review]
patch from Mark J Cox <[e-mail]>

a=asa (on behalf of drivers) for checkin to the 0.9.9 branch and the 1.0 trunk

Comment 4

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 72157 [details] [diff] [review]
patch from Mark J Cox <[e-mail]>

sr=shaver.

(This crash is a security issue, but all our others aren't? =) )

Comment 5

[Daniel Veditz [:dveditz]]

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".

Comment 6

[Daniel Veditz [:dveditz]]

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?

Comment 7

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 8

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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.

Comment 9

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 10

[Christopher Blizzard (:blizzard)]

Please make sure you wait until after the 11th please.

Comment 11

[Mitchell Stoltz (not reading bugmail)]

Attachment: The original bug report

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

Comment 12

[Scott MacGregor]

I just landed this on the AOLTW branch.

Comment 13

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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

[Michael Buckland]

Plussing for AOLTW

Comment 15

[Daniel Veditz [:dveditz]]

We have shipped a fixed version, and the vulnerability is public. Opening bug

Comment 16

[bsharma]

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.

Comment 17

[Daniel Veditz [:dveditz]]

bug 89595 is a completely different bug. Try the image referenced in the 
attached bug report.

Comment 18

[bsharma]

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.

Comment 19

[Mitchell Stoltz (not reading bugmail)]

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
[e-mail]; let's not argue about it here in the bug.

Comment 20

[bsharma]

Added AOLTWOK in the Status Whiteboard.

Verified on 6.2.2 on WinNT and MacOSX