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: Thu, 4 Aug 2005 11:26:42 -0700
From: Berend-Jan Wever <berendjanwever@...il.com>
To: Aviv Raff <avivra@...il.com>, bugtraq@...urityfocus.com, 
	full-disclosure@...ts.grok.org.uk, security@...illa.org
Subject: Re: Mozilla Firefox InstallVersion->compareTo()
	vulnerability lowered severity status

 In short: Setting up complicated structures and knowing where they are 
should be rather trivial and if what you claim is true, this could be 
exploitable with a high degree of success.
 Details: It would be pretty easy to implement setting up three kinds of 
heap blocks; instead of running the heap block creation once, you run it 
three times to create three different kinds of information in three 
different locations. You can predict where the blocks will roughly be 
located since they're so large. In IE, large heap blocks (>=0x00400000 bytes 
IIRC) will always be allocated at an address ending with 0000, making exact 
placement of structures up to 0x10000 bytes big trivial. Assuming FF uses 
the same heap manager, you can setup complicated structures at known 
locations. Assuming what Aviv Raff is claiming about the vulnerability, this 
sonuds exploitable with a high degree of success.
 Cheers,
SkyLined
 On 8/4/05, Aviv Raff <avivra@...il.com> wrote: 
> 
> Hi,
> 
> After more than 2 weeks of no response from the Mozilla Foundation (https://bugzilla.mozilla.org/show_bug.cgi?id=295854), 
> I've decided to disclose the following information:
> Version 1.0.5 of Firefox has fixed a vulnerability in the 
> InstallVersion->compareTo() function that could potentially allow remote 
> code execution. 
> The Mozilla team have decided to set the severity status of the 
> vulnerability to 'Moderate', instead of a higher severity status, claiming 
> an exploitation of this vulnerability requires a predictable address, which 
> means it's almost impossible to exploit. 
> This is partly true. A script can be easily built to significantly 
> increase the possibility of a successful exploitation.
> An attacker can use Skylined's Heap spraying method (used in "Internet 
> Exploiter" - 
> http://www.edup.tudelft.nl/~bjwever/advisory_msie_R6025.html.php), to fill 
> the heap with fake data and vtbl structures that will point to the exploit 
> code.
> This can be done by spraying 3 heap blocks - "data" block, "vtbl" block 
> and "exploit" block - instead of one, as was presented by Skylined. The 
> "data" block will point to a "vtbl" location which will be exactly the eax 
> address + the heap block size. The data in the "vtbl" block will point to 
> the "exploit" block which will be exactly the pointed "vtbl" address + the 
> heap block size. The "exploit" block, of-course, will have the exploit code, 
> padded with nops. 
> This will boost the possibility that the eax address, specified by the 
> attacker, will fall into the faked "data" block. Other methods can be 
> applied to increase the risk even more. 
> Therefore, my suggestion to the Mozilla Foundation is to raise the 
> severity status of the vulnerability to 'High' or 'Critical'. 
> 
> Best regards,
> Aviv Raff. 
> 


-- 
Berend-Jan Wever <berendjanwever@...il.com>
http://www.edup.tudelft.nl/~bjwever

Content of type "text/html" 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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ