full-disclosure - Re: firefox 2.0.0.2 crash

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] [thread-next>] [day] [month] [year] [list]

Date: Fri, 09 Mar 2007 17:27:34 -0500
From: Valdis.Kletnieks@...edu
To: "M. Shirk" <shirkdog_list@...mail.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: firefox 2.0.0.2 crash

On Fri, 09 Mar 2007 16:33:58 EST, "M. Shirk" said:
> 0x8040 through 0x9D40 Crash
>
> But 0x9E40 does not crash (72x40512) :-)

Shooting in the dark here - I wonder if that's being treated as a signed number
and thus negative, and from 0x8040 to 0x9D40 lands it on something that's
immediately critical and causes a crash, but 0x9E40 lands on some memory that
isn't used very soon, thus avoiding an immediate crash but producing
destabilizing results down the road, like your bookmarks evaporating, or
strange infinite loops, or any of the other usual symptoms of random
fandango-on-core memory overlays....

One has to wonder if any offset happens to land on something that eventually
leads to a remote-code-execute.

Content of type "application/pgp-signature" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/