Placeholder bug for patching the zlib double-free problem
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).
Summary: zlib double-free → zlib double-free can lead to crash
Created attachment 72157 [details] [diff] [review] patch from Mark J Cox <email@example.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
Comment on attachment 72157 [details] [diff] [review] patch from Mark J Cox <firstname.lastname@example.org> 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 <email@example.com> sr=shaver. (This crash is a security issue, but all our others aren't? =) )
Attachment #72157 - Flags: superreview+
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".
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.
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.)
Plussing for AOLTW
We have shipped a fixed version, and the vulnerability is public. Opening bug
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 → ---
bug 89595 is a completely different bug. Try the image referenced in the attached bug report.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago → 16 years ago
Resolution: --- → FIXED
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 firstname.lastname@example.org; let's not argue about it here in the bug.
Added AOLTWOK in the Status Whiteboard. Verified on 6.2.2 on WinNT and MacOSX
Whiteboard: AOLTW+ → AOLTW+, AOLTWOK
You need to log in before you can comment on or make changes to this bug.