Re: Mozilla Firefox InstallVersion->compareTo() vulnerability lowered severity status

[Berend-Jan Wever <berendjanwever () gmail com>]

 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 () gmail 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 () gmail com>
http://www.edup.tudelft.nl/~bjwever

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