Re: Why metasploit's exploits fails inside Qemu?

["Mark A. Miller" <mark () mirell org>]

On Wed, Sep 22, 2010 at 11:12 AM, AK <platsakos () gmail com> wrote:

> 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

I sincerely doubt it's a timing issue, since the entire emulation is
self-contained, and any system calls or other interrupts into the execution
would stop the entire emulator, not just the particular code in question.

What's far more likely is that TCG (Tiny Code Generator) in QEMU is
optimizing away some of the code, either before the exploit runs, or the
exploit itself. (TCG was initially designed as a C-backend for a
cross-compiler, after many years of suicides and death threats against the
GCC developers and shut-x86-gnu-linux-up tuples.)

I haven't had a chance yet to look at this particular exploit under QEMU,
but I'd recommend attaching gdb to QEMU to see what exactly is executing
(You can set up a gdb network interface with -gdb).

Also, I'd have a look at tcg/tcg.c, specifically disabling this particular
option:

/* define it to use liveness analysis (better code) */
#define USE_LIVENESS_ANALYSIS


This is located in: http://git.qemu.org/qemu.git/tree/tcg/tcg.c I'd also
look at http://git.qemu.org/qemu.git/tree/tcg/README for a general overview
on how TCG works. It's not trying to be a dumb emulator, since otherwise
that would make emulation is slower. Not good!

I'll look at this exploit specifically later when I have some more free
time, but I'd start there. Also I'd be curious if VirtualBox or VMware
perform the same way.

-- 
Mark A. Miller
mark () mirell org

"1997 will be the year that the browser mates with the desktop." - Adam
Schoenfield, Vice President of Juniper

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