Re:Re: [Qemu-devel] How to make shadow memory for a process? and how to trace the data propation from the instruction level in QEMU?

[F. Zhang]

>Mulyadi Santosa writes:
>
>>> Yes, I have read that paper, it’s wonderful!
>>> 
>>> Besides the Argos, the bitblaze group, led by Dawn Song in Berkeley, has
>>> achieved great success in the taint analysis. The website about their
>>> dynamic analysis work (called TEMU) can be found at:
>>> http://bitblaze.cs.berkeley.edu/temu.html
>>> 
>>> And TEMU is now open-source.
>
>> Thanks for sharing that...it's new stuff for me. So, why don't you
>> just pick TEMU and improve it instead of...uhm...sorry if I am wrong,
>> working from scratch? After all, I believe in both Argos and TEMU (and
>> maybe other similar projects), they share common codes here and there.
>
>> But ehm...CMIIW, seems like TEMU is based on Qemu 0.9,x, right? So
>> it's.... sorry I forgot the name, the generated code is mostly a
>> constructed by fragments of small codes generated by gcc. Now, it is
>> qemu which does it by itself. So, a lot of things change
>> (substantially).
>
>I haven't read the TEMU work, but from the problem description I think
>you want something similar to "Practical Taint-Based Protection using
>Demand Emulation" or many others (I remember reading some of them a few
>years ago on the ISCA, MICRO and/or ASPLOS conferences).

 Yes! That is just what I want. A practical taint-analysis environment plus a demand emulation.

This topic includes things that I recognized as critical. Have you any suggestions?

 

 >>> Yes. For each process’s memory space A, I wanna make a shadow memory B. The
>>> shadow memory is used to store the tag of data. In other words, if addr in
>>> memory A is tainted, then the corresponding byte in B should be marked to
>>> indicate that addr in A is tainted.
>
>The main question here is... what is the granularity that you want to
>track with? Bytes? Words? Pages? This will greatly influence which is
>your best approach.

 

 I think one byte per tag is necessary for malware analysis in most cases, because only a few bytes are used to launch an attack. For example, a few tainted bytes sent to EIP register will cause CPU to do bad things.

>
>Now that I think of it, you could use the tracing points I sent for
>guest virtual memory accesses, and instrument them instead of calling a
>file-tracing backend (this should provide a hook for an arbitrary
>granularity). Then, simply keep track also of address-space changes and
>your instrumentation code can always know when to activate propagation.
>

 

Sorry, what is “a file-tracing backend”? Could you be a little more detailed? I think I need byte-level granularity. Thanks!

 

>This, together with the optimization I sent for dynamic control of trace
>generation in TCG emulation code should get you on tracks.
>
>Of course, you should still modify all register-accessing instructions
>to propagate information passing through the register set. For that,
>maybe you could start with the "fetch" tracing/instrumentation point I
>sent long time ago, which keeps track of general-purpose register
>usage/definition on x86 (although I'm sure I left some astray usages due
>to the decoding complexity in x86).

 

Thanks! I will read that code first, though I am currently just a newbie. L

 

>
>
>>> The guest os collects “higher” semantic
>>> from the OS level, and the QEMU collects “lower” semantic from the
>>> instruction level. Combination of both semantics is necessary in the
>>> analysis process.
>
>> The question is, in a situation where malware already compromise "the
>> higher semantic", could we trust the analysis?
>
>Beware, I've read exactly this kind of scheme on previous top-tier
>conferences (but I think tests were using an architectural simulator, so
>it's not for a current production environment).
>
>I've found it :)
>
>     Secure program execution via dynamic information flow tracking
>     ASPLOS 2004
>
That is a significant paper, which is cited for more than 300 times!

 

>>> The question is: how to communicate between the QEMU and the guest OS, so
>>> that they can cooperate with each other?
>
>A few choices here, but you should first define if the communication
>must be based just on control signals, and/or providing memory storage:
>  * virtual device : If you need some kind of storage that the guest OS
>    must access, you could look at the ivshmem device
>  * backdoor instruction : It's the simplest option; I sent some patch
>    series recently with two different implementations for x86.
>
>

 

Both of control signals and (shadow) memory storage are required. So, the virtual device may be the right choice.

 

In this year’s top security conferences (Oakland, CCS, Usenix Security, NDSS and so on), many works are based on virtual technology. So I think QEMU is a good choice for future academic research.

 

Thank you very much for your time and help!

 

Best regards!

 

F. Zhang

---

网易163/126邮箱百分百兼容iphone ipad邮件收发