Re: Why metasploit's exploits fails inside Qemu?

[AK <platsakos () gmail com>]

Hi everyone,

For starters, I second the timing thought, sometimes emulation
(especially if it struggles to keep up) is not able to keep the same
timings (based on OS priorities)

Additionally, there have been examples of exploits working perfectly on
physical and failing under virtualized environments. CVE-2010-0232
springs to mind. While some versions of the exploit code worked
perfectly on physical, under VMs it failed and crashed. The following
post provides additional information for what triggered that particular
case:

http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2007-05/msg00073.html

Obviously, the above apply more to kernel-land than userland.

Virtualization, while certainly usable and having "matured" a lot in the
past few years, still have a few gotchas when operating in conditions
such as exploitation.


On 09/22/2010 05:42 AM, Jun Koi wrote:
> On Wed, Sep 22, 2010 at 9:25 AM, Philip Sanderson
> <philip.k.sanderson () gmail com> wrote:
>   
> > General ideas:
> >   - If it heap sprays, it may not have completed the heap spray before the
> > vuln is triggered, thus returning to memory too early.
> >   - depending on what is being exploited, it might be cleaning up threads /
> > resources before it's triggered.
> >
> > Just related to time, and that it is significantly slower emulating vs
> > hardware acceleration.
> >
> >     
> sorry if i misunderstand your idea, but this doesnt make much sense to
> me: it is true emulation is slow, but then the whole system is slow,
> not just
> the exploitation procedure.
>
> actually Qemu is not as fragile as people might think. emulation in
> Qemu is pretty good, so that pretty much all applications (and a lot
> of OS-es) works perfectly. Metasploit seems to be one of few
> exceptions :-)
>
> thanks,
> Jun
>   

_______________________________________________
https://mail.metasploit.com/mailman/listinfo/framework