bugtraq - Re: [Full-disclosure] Firefox onUnload + document.write() memory corruption vulnerability (MSIE7 null ptr)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.58.0702252330330.21707@dione>
Date: Sun, 25 Feb 2007 23:40:53 +0100 (CET)
From: Michal Zalewski <lcamtuf@...ne.ids.pl>
To: Stan Bubrouski <stan.bubrouski@...il.com>
Cc: Daniel Veditz <dveditz@...zio.com>,
	full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com,
	security@...illa.org
Subject: Re: [Full-disclosure] Firefox onUnload + document.write() memory
 corruption vulnerability (MSIE7 null ptr)

On Sun, 25 Feb 2007, Stan Bubrouski wrote:

>>>   http://lcamtuf.coredump.cx/ietrap/testme.html
>> This bug was fixed in 2.0.0.2, released Friday Feb 23.
> No it most certainly wasn't, do your homework next time.

Actually, the story is kinda funny, but yeah, it seems that it's fixed
now.

The story: I reported the problem a day before 2.0.0.2 was to be released.
Mozilla dev team looked into this, but - if I understand correctly -
decided to go on with 2.0.0.2 as planned, without a fix for this vuln,
then follow up with a quick release of 2.0.0.3 to address the problem.
This seemed like a sane decision - 2.0.0.2 had been postponed previously,
so there seemed to be no point in holding back.

When 2.0.0.2 went live, some devs noticed that it doesn't crash with my
testcase, though it still crashes trunk builds. After a brief moment of
confusion, they determined that a fix for an unrelated, obscure
non-security bug 364692 had altered the behavior this vulnerability
depended on, accidentally rendering 2.0.0.2 not vulnerable to the attack.

This was then fixed on trunk, and voila. I can't really comment on whether
this fixes the problem once and for all, because I haven't really examined
the changes implemented for 364692, but yeah, my example no longer crashes
the browser for me.

/mz