Flag: Tornado!
Hurricane!
|
|
Topic created on: June 29, 2006 16:31 CDT by MohammadHosein  .
interesting , joanna says she is going to present a tech which is able to bypass vista-x64's singed-only kernel module loading restriction , and i think this is a very important "political" release ;-) hahaha
( i really like these girlish names , svv , bule pill ...:P )
http://theinvisiblethings.blogspot.com
A rootkit will _always_ be detectable, calling it "100% hidden" or whatever is just, sadly, marketing talk, and I'd hope that this community doesn't turn commercial with such PR talk.
I can think of, right now, several methods of detecting Blue Pill, and none of them rely on any flaws in Pacifica.
Kudos on the great work and this will really be a cool field to study (at REcon I was discussing this with some people involved with Hypervisor technology) because rootkits now have an even higher (as in power) level to subvert, but it's irresponsible and foolish to call things undetectable...
|
Remember the VX magazines from the 90s? Almost every issue will had an article about a cool new technique for writing "undetectable" viruses. Our community has a long tradition of making very strong claims that are often disproven.
What do you mean by "irresponsible"?
|
> asotirov:
>
> What do you mean by \"irresponsible\"?
I guess I meant that it's "false advertising" in the sense that it might give false hope. Imagine a corporation with a valid reason for using Blue Pill (covert surveillance, God knows what, pick something), thinking it's "100% undectable". The next day, their software gets completely compromised and turned against them. Lives could be lost.
I know it sounds like a scenario from a movie, but there really are lots of critical places that depend on software to work as advertised...
|
> AlexIonescu: A rootkit will _always_ be detectable, calling it \"100% hidden\" or whatever is just, sadly, marketing talk,
I partly agree on what you said (calling anything 100% anything is risky). But I also think Blue Pill is a really good idea, and I think it could be made undetectable (Think you load a perfect vmware before the os, and do everything from outside).
If you are talking about using a bug in Blue Pill to detect it, then we get in the infinite arms race, which is still interesting to see.
I don't know more than theory on Hypervisor, and any discussion on the subject will be great!
So, please share all your several methods of detecting Blue Pill!
|
The hypervisor will be quite nice for detecting and preventing rootkits actually. Using the hypervisor for malicious purposes seems unlikely if the operating environment already uses the hypervisor as part of its security architecture.
I blogz0rd about this a few days ago if your interested:
http://www.rootkit.com/blog.php?newsid=523
I'm more interested in the kernel bypass to be honest...
ps. Hey Pedram, thanks for making the EDIT button bigger so I could see it and fix my splelling mistakes :-/
> AlexIonescu: A rootkit will _always_ be detectable, calling it \"100% hidden\" or whatever is just, sadly, marketing talk, and I\'d hope that this community doesn\'t turn commercial with such PR talk.
>
> I can think of, right now, several methods of detecting Blue Pill, and none of them rely on any flaws in Pacifica.
>
> Kudos on the great work and this will really be a cool field to study (at REcon I was discussing this with some people involved with Hypervisor technology) because rootkits now have an even higher (as in power) level to subvert, but it\'s irresponsible and foolish to call things undetectable...
|
> Opcode: To Alex Ionescu:
> http://theinvisiblethings.blogspot.com/2006/07/blue-pill-hype.html
>
> Regards,
Well with that being said, I rest my case.
"A step towards 100% undectable malware in practice" sounds a lot more rational.
Like I said, I think it's a great idea and I greately respect this work, I've never put that in doubt.
Gera: Playing with interrupts, precision timing, unemulatable opcodes (I think Pacifica is supposed to provide one), loading your own hypervisor first, booting from another installation media and doing a scan from there (I don't understand why she says people should stop giving this idea, just because the malware installs itself on the fly doesn't mean it's not already somewhere on disk as a file to execute...), etc (it all depends on how it was implemented, really). Sure most of these are painful and hard to make into a viable A/V software for a newbie user, but they're still possibilities that could be researched.
Greg: I've been investingating two such methods, but one requires a reboot... however, I'm sure Joanna has something more elegant.
|
This may sound really dumb coming from the other direction - but future malware strategies that *work* are probably *not* going to be super-low-level. The reason isn't hard to grok - it's just that lower level places are *small* and *easy to observe* where as the chaotic and insane world of installed applications just seems like a thing the NOONE will ever get a handle on. If I had a choice of where to hide, I wouldn't be choosing the hypervisor. I would put something in some stupid temp directory used by some insecure application - noone, not even the Symantecs of the world, are gonna detect this. On the other hand, if I try to get $cute$ and make a hypervisor mod, chances are a bezillion to one that some smart-ar$e PhD out there is gonna have a way to detect me :-) It's just common street-sense.
|
|
Certainly, you don't want to cram your entire malware package into the hypervisor. You just want it to help you out by hding a memory page here, a disk sector there, and maybe redirect some I/O ports and such, right?
|
Her technique is one that is apparently rather obvious; I had it on my weblog in the beginning of June. I'm sure Joanna thought of it before me, but if I thought of it, so did many others, and so did Microsoft.
Expect Microsoft to block raw disk access to everything but kernel drivers.
Melissa
|
Expect Microsoft to block raw disk access to everything but kernel drivers.
so many applications stop working then
|
|
i chose to see the truth, btw where is it ? perhaps with the generic usb flaw of the last year :p
|
> AlexIonescu: A rootkit will _always_ be detectable, > I can think of, right now, several methods of detecting Blue Pill, and none of them rely on any flaws in Pacifica.
>
Yes, I think so too. I don't what is your method you mentioned though. And I have a way to detect this "100% undetectable malware".
To detect the existence rootkit of executing in a hardwared-VM environment, we can break it into two parts:
Detecting the hardwared-VM environment, and next is to differentiate between a VM that is compromised by rootkit, vs one that is not.
Comparing a machine with VM to another without a VM, the one with the VM will have more instructions to execute, and thus will be slowed down relatively. But because the clock offset is corrected, DURATION of execution appear the same in both system. (This is in one of the diagram in Joanna's presentation, where the timing offset is corrected (VMCB.TSC_OFFSET = -tx), so as to disguise any time delay when executing the instructions like RDMSR in the hypervisor.) Yes, you can offset the clock to mask out the time delay when executing in the hypervisor.
But once you do it a billion times, it will become a time skew, WITH RESPECT TO AN EXTERNAL CLOCK. And it can be noticed that the clock skew is growing wider and wider. Next he will stop executing this instruction completely. But executing another like "INC RAX, PUSH RBP" etc, billions times over. Then he will attempt to measure the clock timing differences again, and noticed there is no timing skew at all. So this eliminate the possibility that the physical clock is defective.
Next, is to differentiate between a rootkit-compromised vs non-rootkit-compromised VM.
Again, timing analysis can easily differentiate as the path with rootkit execution vs one without rootkit is going to take a different number of instructions executed.
|
> AN EXTERNAL CLOCK. And it can be noticed that the clock skew is growing wider and wider.
The CPU expense of a VMExit transition came up the other day in a meeting, apparently just the guest to root transition is 8000ticks on a Xeon 50XX Dempsey and down to around 5000ticks on a Xeon 51XX Woodcrest, either way thats still a whole lot of ticks for something that could be relativly simple operation. (those are for the transition and not the handling of the exit too). Not sure what the Pacifia times are but im sure they are ballpark anyway. It would be interesting if someone tried this time skew out by running a tight loop of a try/except that always throws an exception, does an int3, whatever. I still havent seen the slides yet but regardless of what you do there should be margin for timing attacks.... with a STOPWATCH! =P
|
wrote out a bit of code to test the timing attack to see what the skew was like and was pretty suprized. Posted a rootkit.com article which is still awaiting moderation but the code is up now in my vault for those interested....
http://www.rootkit.com/download.php?browse=1&user=bugcheck
|
> bugcheck: wrote out a bit of code to test the timing attack to see what the skew was like and was pretty suprized. Posted a rootkit.com article which is still awaiting moderation but the code is up now in my vault for those interested....
>
> http://www.rootkit.com/download.php?browse=1&user=bugcheck
That's awesome, I'll take a look at it.
OT: Just noticed you're from Canada...which city?
|
Yeah skew times of trapping an rdtsc is a factor of 1000-2000x. Not trapping it you still have a skew of 40 while adding the TSC_OFFSET so executing it a bunch show diffs of 5 seconds worth of rdtsc's balloon up to over a minute. If you try and trap it and fudge it your looking at an hour.... Either way you don't need an external *device* and really you can try and determine the tick time resolution and see it programmaticly if taking an hour to run doesn't convince you enough =) Trying to get around this rdtsc to trick the utility will totally screw over your system but I suppose its probably theoretically possible to get a false negative. The only real attack that 'works' would be to kill it and fudge printf's which of course is lame.
Ottawa area but I'm currently doing work down in the US and will probably stay down here for a couple more years. Eventually id like to move back home though.
|
Note: Registration is required to post to the forums.
|
|
|
|
There are 31,313 total registered users.
|
|
![[+] expand](/imagery/files/soysauce_blueprint.gif){kind=link}