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: <8beca82050805034931b9971a@mail.gmail.com>
Date: Fri, 5 Aug 2005 12:49:41 +0200
From: Aviv Raff <avivra@...il.com>
To: Berend-Jan Wever <berendjanwever@...il.com>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com,
	security@...illa.org
Subject: Re: Mozilla Firefox InstallVersion->compareTo()
	vulnerability lowered severity status

Hi SkyLined,
 This is more than just a claim. 
I am using facts that were presented in the Bugzilla post by Shutdown, and 
were accepted by the Mozilla team.
Combining those facts with your heap spraying method in mind, make this 
vulnerability a high risk that should be addressed as one in the advisory. 
 As I've already stated before, exploiting the vulnerability this way is not 
an hard task as the Mozilla team presumed in their advisory, by setting the 
severity status to 'Moderate'.
 Best regards,
Aviv Raff
 On 8/4/05, Berend-Jan Wever <berendjanwever@...il.com> wrote: 
> 
>  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