Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

VM-Based Rootkits Proved Easily Detectable

kdawson posted about 7 years ago | from the take-one-blue-pill-and-call-me-in-the-morning dept.

Security 128

paleshadows writes "A year and a half has passed since SubVirt, the first VMM (virtual machine monitor) based rootkit, was introduced (PDF), covered in the tech press, and discussed here. Later Joanna Rutkowska made news by claiming she had a VMM-based attack on Vista that was undetectable — a claim that was roundly challenged. Now in this year's HotOS workshop, researchers from Stanford, CMU, VMware, and XenSource have published a paper titled Compatibility Is Not Transparency: VMM Detection Myths and Realities (PDF) showing that VMM-based rootkits are actually easily detectable."

Sorry! There are no comments related to the filter you selected.

First to say... (-1)

cicatrix1 (123440) | about 7 years ago | (#20820199)

pwned

Re:First to say... (-1, Flamebait)

Corwn of Amber (802933) | about 7 years ago | (#20821125)

Of course.

Seriously, VMWare or any other solution will always be running at, what, 10% of native speed?

Thus, if you run your WHOLE F*ING ENVIRONMENT on top of a VM, it WILL be noticed - Know what? A 90% decrease in speed IS OBVIOUS.

Morons.

If you think "there are ways to make it fast" then stop. Stop thinking. Instead, go write your own VM and kill VMWare and QEmu and Bochs and Plex86 and Xen and so on, because you are so much smarter than all their devs.

Re:First to say... (5, Insightful)

sokkalf (542999) | about 7 years ago | (#20821283)

VMWare is virtualization software, not emulation software. It runs pretty close to native speed, depending on what you run on it. Comparing it to bochs is just stupid, that's a full blown emulator. A VM still uses your processor natively to decode the majority of instructions, it just catches the privileged ones, that otherwise would make your OS go boom. (Simply put)

Re:First to say... (0, Flamebait)

Corwn of Amber (802933) | about 7 years ago | (#20822061)

Depending what you run on it? Let's say "anything that makes the load go above 1 on *N*X".

Let's say "OpenOffice". It takes a year and more to load, so running it on any kind of VM will make that two years and more... (replace "years" by something less exaggerating)

"Even granpa" will notice. Yes. Even Granpa notices when the computer becomes really, really unusable. A VM to run a bot-infested machine? BWAHAHA. Welcome back, 8086 @ 4,77MHz.

Virtual Virtualization (1)

goombah99 (560566) | about 7 years ago | (#20822475)

As you say, a real VM does execute instructions directly and either traps memory calls in hardware or traps all the system calls or both, it's not emulation. Stacking one virtual machine inside another one is quite thinkable since even two steps down the machine is still executing native instructions not emulating them so the speed loss is not multaplicative

For that reason I fully expect in the not too distant future that we will have virtual machines running inside virtual machines. That is there will be a move towards more compartmentalization. OS's will spawn virtual machines for any untrusted process, maybe all of them. And then pass messages between them. It's reasonable to assume the OS may in turn sit on top of some lightweight virtual machine. Perhaps embedded systems will use some stripped down real-time OS on the bottom for guaranteed execution perfromance and then also host virtual machines to allow richer application contexts for more sophisticated apps than the real-time OS will support.

Indeed anyone who has ran a virtual machine after getting hit with the Sony root kit was in fact already running a virtual machine within a virtual machine. People who timeshare on racked servers may well already be renting a virtual machine and they in turn maybe instantiating virtual machines.

At this point all the detection modalities in the paper go out the window. The only part of the system that can actually have a shot at detecting it is not retro-VMed by a virus is the bottom one and that may not be one even the machine owner is allowed to touch. For example, perhaps some form of trusted computing will emerge where the primary OS that is simply a virtual bios that hosts the OS will be be burned into the hardware itself.

Re:Virtual Virtualization (0)

Anonymous Coward | about 7 years ago | (#20822885)

Indeed anyone who has ran a virtual machine after getting hit with the Sony root kit was in fact already running a virtual machine within a virtual machine
You give the rootkit too much credit, it just patched the kernel. Nothing to do with VMs or Virtualization.

Re:First to say... (3, Interesting)

dc29A (636871) | about 7 years ago | (#20823941)

VMWare is virtualization software, not emulation software. It runs pretty close to native speed, depending on what you run on it. Comparing it to bochs is just stupid, that's a full blown emulator. A VM still uses your processor natively to decode the majority of instructions, it just catches the privileged ones, that otherwise would make your OS go boom. (Simply put)
I had to port this major banking application to VMWare ESX (in a VM running Windows 2003). I have to agree with your "runs pretty close to native speed, depending on what you run on it" comment. My only beef is that, "depending on what you run on it" is extremely limited.

On a native machine, we achieved about 55-70 transactions per second, after that, the CPU of the machine was maxed out. This was a quad Xeon with about 16 gigs of ram. The same exact machine, running ESX host, and one single VM, one, our Windows 2003 server, was able to achieve about 2-5 transactions per second before the host throwing in the towel. Now I am sure ESX 3 will be faster. This wasn't ESX 3, was 2.something.

What I noticed was that:
- VMWare has a lot of trouble with applications who do a lot of context switches. Basically, object pools with significant usage. If the CPU has to swap from thread to thread, it kills VMWare.
- We did a few network tests with bizarre results like VM network latency being 50% more. This is a killer with any system remotely trying to get a decent transactions per secon. We had to de-virtualize our SQL server and SNA gateway, it wasn't able to hold the load.
- For some odd reasons MOM, anti-viruses and SMS can choke a host without any problems. My hypothesis is that missed file cache is brutal for VMWare, especially if other VMs are doing some I/O intensive stuff.

I wouldn't recommend anyone putting a server with moderate to high load as a VM. However, VMWare is awesome for very low load server, we can pack 6-10 of these servers easily on the same dual dual core Xeon. And could probably more.

Re:First to say... (-1, Flamebait)

Anonymous Coward | about 7 years ago | (#20821443)

Uh, go try VMware (free download by the way) before commenting dumbass.

Well, here's the thing (0)

Anonymous Coward | about 7 years ago | (#20821541)

VMWare runs significantly faster than 10% native. So your basic premise falls apart.

And the attack is completely plausible. The fact that I can't write a VM Machine in no way invalidates that premise. It just means that I can't write a VM.

Re:First to say...definitely way faster than 10% (1)

jerkyjunkmail (590408) | about 7 years ago | (#20822421)

kinda sounds like rainman. VMs...definately faster than 10%. definitely.

I don't know man, I've been playing with VMware server running on a really modest 2.4Ghz P4 with 2GB of ram and I've been pretty impressed with it's speed. I'm sure there are some tasks will make the machine take a real beating making the lag more pronounced but I typically have 3-4(lately CentOS, WinXP and a pair of Win2003) guests with the XP host subtituting as my Windows desktop using a really basic Ubuntu install as the host. It actually reboots VMs faster than physical hardware(Win2003 comes up in about 10 seconds after clicking the start vm button) and a start to finish Windows install took about 10-15 minutes from initial boot to a functioning login prompt. Maybe it might be noticable but I'm at least open to many scenarios where it could be pretty convincingly hidden from the layman. I can't imagine how it would run if it had something more recent like a AMD X2 or Core 2 based machine at it's disposal. My hardware is 3+ years old.

jerky

I may be mistaken... (1)

nonsequitor (893813) | about 7 years ago | (#20820235)

I may be mistaken, but I thought blue pill was similar to a VM, but was actually a hypervisor exploit. It sounds to me like having dedicated root kit support built into the chip via the hypervisor would be different than running an OS image inside a software based virtual machine.

Re:I may be mistaken... (2, Informative)

donscarletti (569232) | about 7 years ago | (#20820359)

Virtual Machine Monitor and Hypervisor are synonyms. Hypervisor however generally implies a monitor running on the bare hardware (type 1 virtual machine) whereas VMM may also refer to a monitor running as a userspace process on a host kernel (type 2 virtual machine). Thus it is correct to call bluepill either a hypervisor or a VMM.

Generally the term VMM is much more common with implementors of these systems, however hypervisor is easier to say and sounds cooler so its common with users.

Re:I may be mistaken... (3, Informative)

kscguru (551278) | about 7 years ago | (#20824771)

Virtual Machine Monitor and Hypervisor are NOT synonymous - they usually come in the same package, but this is not required.

An example Virtual Machine Monitor without a Hypervisor is VMware Workstation: a small VMM is loaded to run the guest OS, but it is not complete enough to run the system - it has no task switcher, no memory manager, etc. The host OS acts as the hypervisor here - it is the source of highly-privileged operations unavailable to the guest. Another no-hypervisor VMM is KVM: KVM just runs a virtual machine, but depends on the rest of Linux to run more-privileged operations (and Linux itself becomes the hypervisor).

An example Hypervisor without a Virtual Machine Monitor is the partitioning software on high-end IBM, Sun, etc. machines, which allows you to physically partition the processors of the system into several actual machines - partitioned machiens with zero run-time interdependencies. Literally, a "hypervisor" is something which runs at a privilege level higher than the "supervisor" (the OS).

Hypervisors and virtual machine monitors have existed since the 1960s. Nobody confused the terms then. IBM started the confusion with a whitepaper [ibm.com] "inventing" the type 1 / type 2 taxonomy to distinguish between 1960s-modern IBM mainframe architectures (low-end = hypervisor only, high-end = combination hypervisor/vmm) and the VMware Workstation architecture (host OS loads vmm; host OS acts as hypervisor). Note that VMware never claimed Workstation was a hypervisor! Certain communities (Wikipedia, the press) have accepted IBM's whitepaper as gospel truth, thus the prolifieration of "type 1" and "type 2" terms the past several years. (The same community has chosen to ignore academic research in the 1960s and 1996-2005 which used VMM and Hypervisor correctly.)

With apologies to many individuals who are legitimately using correct terminology, some poorly-informed folks are propagating the "type 2 hypervisor" meme to attempt to equate the abilities of a hypervisor/VMM with a VMM. This is not correct: a combination hypervisor/vmm ALWAYS can achieve better performance than separating the hypervisor and VMM - at the cost of creating a more complex hypervisor (ESX requires custom drivers; Xen requires a customized dom0). The fault for this confusion really rests with Intel: their VT extensions (and AMD's SVM response) have made it so easy to create a VMM that some folks are creating a VMM, then marketing it as a hypervisor in a misguided attempt to compete with existing hypervisors (ESX, Xen) instead of competing with other VMMs (VMware Workstation/Fusion, KVM, Parallels Desktop)

To understand what a VMM is, read this ACM article [acmqueue.com] by Mendel Rosenblum. Academic research generally looks at VMMs (ways to run a virtual machine), not hypervisors (ways to run something with less privileges than the hypervisor). A rough gage of the quality of academic work is whether they manage say Hypervisor when they mean Virtual Machine Monitor. Anyone who thinks the two are the same is ignorant of the past ten years of academic research - and anyone ignorant of ten years of research is doing very poor-quality work. (Alas, Wikipedia chose to use the IBM whitepaper for defining terms instead of many years of published, peer-reviewed papers. Great "neutrality", folks!)

I also may be mistaken... (1)

JordanL (886154) | about 7 years ago | (#20820877)

But why is this article tagged Sony? The Sony rootkit was done by a content division of the company like, what, two years ago? And it wasn't even a VM rootkit.

Or are the sheeple waving their "Never forget" banners loudly?

Re:I also may be mistaken... (2, Insightful)

Xiph (723935) | about 7 years ago | (#20820933)

Actually, when people are being aware of how they're mistreated, and protest it loudly (enough for others to notice), I don't think they qualify as being sheeple.
Well, maybe except those who still buy sony music.

I stopped buying music-cds altogether when one of them installed crap on my winbox.

Re:I also may be mistaken... (0)

Anonymous Coward | about 7 years ago | (#20821757)

Did you also stop using Windows altogether when it allowed crap to be installed automatically from the CD?

Re:I also may be mistaken... (2, Interesting)

Sloppy (14984) | about 7 years ago | (#20824871)

[not be an asshole (but I can't help it)...]

I stopped buying music-cds altogether when one of them installed crap on my winbox.

How did they install crap on your winbox (are you running a ssh server)? I suspect that you installed that crap, or that your OS' virus-support feature installed it for you as a "convenience." Software, no matter how bad, sitting on a CD doesn't just execute itself. Something or somebody (and it wasn't Sony, because they had not yet compromised your machine) decided, "Let's load and execute Sony's malware." Find out what that something or somebody is, and you've found your real problem. Avoiding Sony won't really help you.

Not that Sony has any excuse for offering malware with their music. But don't accuse them of installing it, because they didn't.

Re:I may be mistaken... (0)

Anonymous Coward | about 7 years ago | (#20822727)

Double column PDF = t34 80r1n6

why I like open arch/code (1)

shawn443 (882648) | about 7 years ago | (#20820241)

Until there is openness from the processor, bios, user software, and everything else through and through, who knows.

Re:why I like open arch/code (2, Insightful)

jimicus (737525) | about 7 years ago | (#20820723)

Where exactly are you going to buy a complete system with a fully documented processor, BIOS (or equivalent firmware) and all component parts right the way down to the Verilog (or [insert chip design software here]) source files?

Bearing in mind that even then you need to prove that the chip you hold is the same one described by the source files, and the only way you can guarantee that is if you control the chip fab which produces the chip. Failing that, I suppose you could skim the top off one and examine it with an electron microscope, but the chip is going to be history afterwards so you need at least two chips - and then how do you prove that the one you leave alone is identical to the one you examined in your handy-dandy scanning electron microsocope?

Note: I'm well aware this is absurd. That's the point.

Re:why I like open arch/code (3, Interesting)

evanbd (210358) | about 7 years ago | (#20820991)

Of course, this basic problem [bell-labs.com] was described quite eloquently by Ken Thompson. He went after the compiler, but the problem of proving that the binary you have matches the source you have is a tricky one no matter what.

There actually are some very clever solutions to try to catch cheating compilers like this, but none of them are trivial. It's a cat and mouse game, and there are actually proofs that winning either side completely is impossible.

Re:why I like open arch/code (0)

Anonymous Coward | about 7 years ago | (#20823011)

There actually are some very clever solutions to try to catch cheating compilers like this, but none of them are trivial
Nor worth linking to or naming?

Re:why I like open arch/code (1)

m50d (797211) | about 7 years ago | (#20824739)

Surely you bootstrap things by hand-assembling a simple nonoptimizing C compiler (nonoptimizing compilers aren't that hard, surely one could be written in assembly), then use that to compile your C compiler (thus getting a binary that matches your source), then use that to recompile itself (so you have a C compiler that can actually run at semi-reasonable speed, and whose binary matches its source assuming you verified its source wasn't doing anything nasty).

Re:why I like open arch/code (2, Interesting)

evanbd (210358) | about 7 years ago | (#20825661)

Now you've simply pushed the problem a level higher, into the assembler / linker. Yes, it helps, but there are other techniques as well.

The most elegant technique I've seen goes like this. Maintain trusted dead-simple non-optimizing compiler A (possibly on a different machine). You also have untrusted compiler B, and it's alleged source SB. Compile SB with B, resulting in B. Compile SB with A, resulting in B'. These binaries will be different, but should be functionally equivalent -- B' is probably larger and slower, thanks to having used non-optimizing compiler A to make it. Now, use B' to compile SB, resulting in B''. Since B' and B should produce equivalent output, B and B'' should be bitwise identical. If they're not, you have a problem.

At this point, you simply (heh) have to trust that your OS isn't playing games like showing you different binaries than its running and such. Again, there are similar techniques to deal with this, but the problem can't really be removed without establishing a trusted chain all the way back to the chip fab, through the assembler, linker, compiler, and OS. It's a tough problem.

I read the paper (5, Interesting)

suv4x4 (956391) | about 7 years ago | (#20820245)

I'm still convinced that it's possible to make a VM that appaears to software running within as real hardware.

The paper, however, takes a practical approach, examining how some industry standard VM-s operate, such as VMWare and Virtual PC.

Those VM-s take plenty of shortcuts to improve performance, and don't virtualize some instructions, rather remap them, or "shift rings" of execution etc. as much as possible so to take advantage of the hardware while remaining sandboxed. They don't virtualize the clock as well, so you could time the performance.

A rootkit isn't competing with other rootkits based on performance, it does so based on how undetectable it is. It's arguably a different problem. I think we're yet to witness what a full blown VM made to be a rootkit will act like, and whether it'll be detectable.

Re:I read the paper (3, Interesting)

ihavnoid (749312) | about 7 years ago | (#20820323)

The problem is, that if the VM writer tries to take every possible method to make the execution time similar (e.g. make privileged instructions run as fast as non-privileged instructions), it has to slow the faster ones down. Suddenly, even your grandpa will notice something is wrong. The most insane method would be a VM based on a full-blown, cycle-accurate simulator, but that will be horribly slow.

Instead, what I think is it's not *impossible* to detect, but it's *difficult* to detect, because the VM detector is going to need a very very very long checklist to determine whether it is running on a VM or not. To be sure, it must check every possible privilegd instruction's timing, check the system memory's contents using various workarounds (such as DMA), and etc. etc.

Re:I read the paper (3, Interesting)

suv4x4 (956391) | about 7 years ago | (#20820367)

The problem is, that if the VM writer tries to take every possible method to make the execution time similar (e.g. make privileged instructions run as fast as non-privileged instructions), it has to slow the faster ones down. Suddenly, even your grandpa will notice something is wrong. The most insane method would be a VM based on a full-blown, cycle-accurate simulator, but that will be horribly slow.

Two things:

1. You assume the clock isn't manipulated, hence fast commands should be slowed down to match virtualized instructions. Instead the direct instructions may be left running, and the virtualized to skew the clock subtly enough to be undetectable to the naked eye, and match well with the hardware performance to a detector running within.

2. We're soon about to get plenty of cores on desktop machines, where most of the tasks are serial. If a VM would make use of the extra cores to simulate a single core in around 50-60% its native speed, it may prove undetectable to granda who just browses the net and uses Excel.

Re:I read the paper (2, Insightful)

ihavnoid (749312) | about 7 years ago | (#20820441)

Two things again:
1. Do you really wish to manipulate the clock for every non-privileged instruction, which will result in a horrible VM performance?

2. Yes, your grandpa won't notice a 50% slowdown, but your anti-virus software will easily notice. It's either your grandpa doesn't notice and your anti-virus does, or your anti-virus doesn't and your grandpa does (assuming the anti-virus software does a extensive amount of checking)

What I was trying to say was that it takes a painful amount of performance overhead to make it exactly look like a physical machine (if it actually is possible to implement one), so that it would be easily noticed by a user. Hiding from a casual user who occasionally types 'ps' and inspects some well-known files on /proc won't be so hard, but it will be a big challenge to hide from a well-written piece of VM detecting code. Especially if it's running on kernel mode.

Re:I read the paper (2, Interesting)

suv4x4 (956391) | about 7 years ago | (#20820651)

1. Do you really wish to manipulate the clock for every non-privileged instruction, which will result in a horrible VM performance?

The huge majority of time the computer is running "userspace" commands. Do the math.

Yes, your grandpa won't notice a 50% slowdown, but your anti-virus software will easily notice. It's either your grandpa doesn't notice and your anti-virus does, or your anti-virus doesn't and your grandpa does (assuming the anti-virus software does a extensive amount of checking)

The anti-virus can't detect jack since the the rootkit can report any clockrate to it. Remember: the hardware configuration the software sees is what the rootkit opts to report.

Re:I read the paper (0)

Anonymous Coward | about 7 years ago | (#20820755)

As soon as your grandpa connects to the internet, the AV can just poll any time server on the net, including inofficial ones set up by the AV vendor, using different ports and even possibly a different protocol. Indeed, the timing information could even be implicitly included in the communication with the AV update server. Since there's an external server involved, the root kit cannot control all aspects of it unless the update server itself is compromized (if the update server uses public key kryptography to sign its messages, the root kit cannot simply modify the data stream).

Of course there's always the possibility that the root kit explicitly modifies or disables the AV program, but then, that's not different from any other sort of root kit, and can only work if the root kit author knows exactly how to detect and what to change for the specific AV.

BTW, the article actually already mentions the perfect strategy against such root kits: Virtualize yourself, and disable any virtualization inside your virtualized environment.

Re:I read the paper (1)

suv4x4 (956391) | about 7 years ago | (#20820867)

As soon as your grandpa connects to the internet, the AV can just poll any time server on the net, including inofficial ones set up by the AV vendor, using different ports and even possibly a different protocol. Indeed, the timing information could even be implicitly included in the communication with the AV update server. Since there's an external server involved, the root kit cannot control all aspects of it unless the update server itself is compromized (if the update server uses public key kryptography to sign its messages, the root kit cannot simply modify the data stream).

You're honestly giving Internet time servers too much credit if you think of depending for nanosecond resolution on them.

Re:I read the paper (0)

Anonymous Coward | about 7 years ago | (#20821085)

To detect a 50% slowdown, you hardly need nanosecond resolution.

Re:I read the paper (1)

dozer (30790) | about 7 years ago | (#20825145)

> You're honestly giving Internet time servers too much credit if you think of depending for nanosecond resolution on them.

Not at all. Just repeat the operation 500 million times. Even a 15% slowdown is easily detectable.

It seems like you're only picturing one side of the board here. Try to think objectively about what both sides can do.

Re:I read the paper (1)

cibyr (898667) | about 7 years ago | (#20821359)

Remember: the hardware configuration the software sees is what the rootkit opts to report.
This is where this all falls apart. It's pretty trivial to notice if the hardware you're running on has changed, and as mentioned in The Fine Article/Paper, it's bloody impossible to emulate every possible hardware combination out there, or even any of the common ones. I'd love to see an virtual machine that can fool my nVidia driver that it has an 8800 and can run fast enough for even basic desktop usage, let alone any sort of multimedia or gaming. It's just not going to happen.

Re:I read the paper (1)

suv4x4 (956391) | about 7 years ago | (#20821419)

This is where this all falls apart. It's pretty trivial to notice if the hardware you're running on has changed

Trivial for who. How often do you scan and compare your list of hardware devices in normal operation. How often does your mom.
Remember: trojan makers aren't interested in hacking hardened hacker's computer. They're interested in the mythical mom.

If my antivirus will detect hardware changes then it'll whine on actual hardware changes too. We arrive at the fact that Joanna discovered: it'll be god damn impossible to figure out whether your heuristics are part of a legitimate operation or "evil" one.

I know how my parents react when their security software whines all the time - they click the Yes box and forget about it.

If the hardware changes, Windows is going to fail (0)

Anonymous Coward | about 7 years ago | (#20822599)

validation because too much hardware has changed since the system was installed.

Re:I read the paper (0)

Anonymous Coward | about 7 years ago | (#20822693)

How often do you change your hardware? Or, more to the point: How often does your mom? (And I'm not speaking about getting a complete new system, or adding some new stuff, but actually replacing parts!)
I think a popup from the AV asking "Noted changed behaviour. Did you change your hardware?" wouldn't be too common (and if you e.g. have to select a radiobutton without one being preselected, this cannot go unnoticed through the "unconscious click" mechanism).

----
Lies, damn lies and Slashdot:
"Slashdot requires you to wait between each successful posting of a comment to allow everyone a fair chance at posting a comment.

It's been 49 minutes since you last successfully posted a comment"

(And no, I don't make the number up!)

Re:I read the paper (1)

HTH NE1 (675604) | about 7 years ago | (#20825091)

I think a popup from the AV asking "Noted changed behaviour. Did you change your hardware?" wouldn't be too common
And this is why it is soft and hard, not over and under:

"Noted changed behavior. Did you change your underware?"

Re:I read the paper (1)

andreyw (798182) | about 7 years ago | (#20824571)

It doesn't have to, because it doesn't have to be a full fledged multi-VM VMM environment, since the whole point of VM-based rootkits is to move the malevolent code outside of the realm of detectability by the OS. This is why the paper sucks. It makes all these arguments for why existing VMWare, Virtual PC or Parallels solutions are detectable, but that wasn't the point of blue pill.

All you need is a thin hypervisor layer that provides nearly transparent access to the hardware. As far as the OS is concerned - it's still running on the latest chipset with your nVidia card and all that jazz. As the technology for directed I/O virtualization becomes common, it WILL be possible to create what looks exactly like whatever the real hardware is... and the OS running will ne be able to use hardware transactions to attempt at snooping memory to see if there is something else out there.

All in all it's a pretty horribly written paper. It screams of a) sensationalism b) dilletantism and college work.

Re:I read the paper (1)

tqbf (59350) | about 7 years ago | (#20822351)

That's simply not how it works. This isn't DOS, and there isn't a simple BIOS call the OS uses to retrieve the current time. Start here: the X86 has a 64 bit timebase register, the TSC, which reports cycle-count time in about 150 cycles directly from the hardware. Joanna tried to virtualize the TSC and found that she couldn't do it reliably under AMD SVM. She had to resort to dynamic code translation, VMware-style, to detect and modify code that probed the TSC. The problem with that approach is left as an exercise to the reader, who is encouraged to read a few back issues of 40Hex.

It's funny that people can forget the fact that the CPU is itself a clock. Which is why you can time a hypervisor with a simple counter loop, like Edgar Barbosa did. Joanna conceded that she had no effective defense against this approach either.

Re:I read the paper (1)

jmv (93421) | about 7 years ago | (#20820921)

You forget there's two clocks. There's the machine's clock, which you can easily manipulate, but there's also the soundcard clock -- which you can't manipulate without your stuff sounding strange, and then there's the NTP clock, which you can't manipulate at all. And significant difference between all these clocks and a VM is detected. So basically, slowing down everything equally or skewing the local clock isn't an option.

Re:I read the paper (1)

Cheesey (70139) | about 7 years ago | (#20821603)

Actually I think you are wrong. It is known to be very difficult to simulate the timing behaviour of a complex CPU as found in modern desktop PCs, because the timing behaviour depends on so many factors. This has previously been a problem for real-time systems because programs on such complex CPUs have very poor timing behaviour in the worst case.

But it is also a problem if you are trying to hide a virtual machine, because the complexity of operation creates a sort of "timing fingerprint" that is unique to the CPU. The virtual machine would have to mimic this fingerprint correctly for every possible program in order to stay hidden, and current research suggests that this would be an intractable problem for a sufficiently complex CPU, let alone a multi-core architecture with many CPUs all accessing memory simultaneously!

The point is that a VM might be able to hide from a typical user, but it won't be able to hide from every piece of software that could be designed to detect it.

Re:I read the paper (1)

tqbf (59350) | about 7 years ago | (#20822277)

"Undetectable to grandad"? Asinine.

The threat model facing rootkits is not end-user computer savvy. It's conventional anti-malware software. The question isn't whether the person sitting at the computer is smart enough to notice a 60% slowdown. It's whether the impact the rootkit has on the system is reliably measurable, either directly or through a side-channel, in a way that can be harnessed by Norton Antivirus. If it is, you lose; your "undetectable rootkit" is now literally a bullet point on the packaging of a security product, making the AV companies money.

As for the clocks: there are tens of them in a conventional X86 box. You're probably thinking of the RTC, and you may have heard of the TSC. But what about the high performance clocks? The ACPI timers? Or how about the implied timers driving device events? Remember the VGA blanking interval? Assuming you know where all the clocks are, now figure out some protocol to keep all your perturbations of these clocks consistent.

Joanna is doing great work, but it is being totally misrepresented in comments like these. Her challenge is nowhere nearly as simple as the armchair quarterbacks are making it sound.

Re:I read the paper (1)

Sancho (17056) | about 7 years ago | (#20822595)

Suddenly, even your grandpa will notice something is wrong.
This is really a straw-man. The point is indetectability from within the guest OS (i.e. antivirus or whatever security software is running should not be able to detect it.) There are plenty of attacks that you can use to detect the infection from the outside.

Full vm (2, Insightful)

leuk_he (194174) | about 7 years ago | (#20821155)

The current commercial vm's don't try to be undetectable. But if a vm was created with the purpose of being undetectable might be a different matter.

It might be possible to create a vm that only visualizes a specific part of a pc. Only hide some memory and disc space, and passing all other parts through to actual hardware. I don't know if it is feasible.

Re:Full vm (0)

Anonymous Coward | about 7 years ago | (#20822515)

That's discussed in the paper as 'pass-through' - where you let the client have direct access to the physical hardware. The problem with that is that the whole point of the rootkit is that it manipulates the same hardware itself, and thus needs to be able to share the hardware with the client as well as itself.. without the client noticing. The rootkit would almost certainly need to have built-in drivers specific to every possible hardware configuration. Pulling that off to the degree that the hardware behaves precisely the same as if the client had full control of the machine would be very, very difficult.

Re:I read the paper [no you didn't] (1)

tqbf (59350) | about 7 years ago | (#20822193)

You clearly didn't read the paper, because it doesn't simply describe how "industry standard VMs operate". Garfinkel and Ferrie are talking about fundamental X86 architectural issues that make intercepting hardware accesses and emulating them in software perceptable to code running on the same machine. The Blue Pill VMM rootkit doesn't leave important instructions "unvirtualized", but it has to operate within the X86 memory hierarchy, and so remains detectable.

For example, the fact that a transition in and out of the hypervisor flushes TLB entries is not a "shortcut" taken by VMware; it's a design parameter of Intel's VT-x and AMD's SVM extensions. The fact that you can't reliably offset the TSC in AMD's SVM is also not a shortcut. And the fact that you can run a counter loop [rapidshare.com] to detect VM exits regardless of the underlying hardware is not a shortcut.

How, exactly, do you propose that rootkit authors evade these problems?

Re:I read the paper (1)

TemporalBeing (803363) | about 7 years ago | (#20822495)

I'm still convinced that it's possible to make a VM that appaears to software running within as real hardware.
You mean like the Bochs Pentium Emulator [sf.net] ? Because - that is pretty much what they do. They emulate the entire computer, processor included. There was one branch that used a Linux module to use real hardware to speed things up (x86 only), but it otherwise fully emulates the computer including all instructions of the emulated processor and the system timer.

They've done a great job with it. However, it is slower than VMware, Virtual PC, and others though the guest OS is still usable. To do so, it also eats up near 100% of your real CPU and delivers a fraction of the speed of the real CPU, typically 10% though I think they may be doing better than that now on faster processors. (Really good guest OS performances starts with a minimum 1Ghz CPU.) It can also run on non-x86 platforms.

So, try it out. It's great for doing OS development and testing OS's. But don't rely on it for high performance apps or newer games. (Older DOS games would do fine under it.)

Re:I read the paper (1)

tagbo (682269) | about 7 years ago | (#20822883)

I promise you that when/if you find VM rootkits operating in the wild, it would already be too late. Maybe the Wachoski's didnt mess up the ending of the Matrix like most people thought...

Once again proves women are incompetent scientists (-1, Offtopic)

Anonymous Coward | about 7 years ago | (#20820283)

Next let's have a study from Sally Pollyanna about how to drive well.

Re:Once again proves women are incompetent scienti (0)

Anonymous Coward | about 7 years ago | (#20821037)

This will begin with a a 6 page treatise on reversing into solid objects

Missing the point (5, Insightful)

insecuritiez (606865) | about 7 years ago | (#20820311)

Unfortunately, this paper completely misses the point. This paper is not so much about detecting a VM based rootkit so much as it is about detecting VMs in general. The authors argue is that if you detect a VM when you aren't expecting to, you've found a rootkit. Joanna's argument is that in a few years, everything is going to be using VM technology and you won't be able to tell a "good" VM from a "bad" one.

See virtualization-detection-vs-blue-pill [blogspot.com] and her presentation on the subject here [bluepillproject.org] . No one ever said that detecting a virtual machine is impossible. They are saying discriminating between malicious and non-malicious VMs is impossible.

Re:Missing the point (2, Interesting)

julesh (229690) | about 7 years ago | (#20820589)

Joanna's argument is that in a few years, everything is going to be using VM technology and you won't be able to tell a "good" VM from a "bad" one.

I fail to see what purpose the average user has for VM technology. Sure, it's great for server systems, and as a developer I find it extremely handy, but if all you do with your computer is read e-mail, browse the web and run MS Word, why would you want a VM?

Re:Missing the point (1)

EvanED (569694) | about 7 years ago | (#20820891)

Depending on how broadly you wish to interpret what a VM is, you could consider stuff like Apple's Rosetta a virtual machine. It's pretty regular that people around here call for MS to use virtualization to provide an avenue for them to ditch a lot of the backwards compatibility cruft that's causing many of their issues.

These things aren't exactly like running a whole OS in visualization, but some of the same technology is used, and I could see possibilities for using hardware VT support.

Re:Missing the point (1)

Arterion (941661) | about 7 years ago | (#20825195)

I thought Rosetta was an emulator?

Re:Missing the point (1)

EvanED (569694) | about 7 years ago | (#20825769)

What's an emulator and what's a true VM is somewhat blurry. For instance, if my understanding is right, VirtualPC emulates instructions that are executed in ring 0. But most people would still call it a virtual machine monitor.

There are other things, like the Java Virtual Machine, that are also in some sense an "emulator" -- but it's emulating a machine that runs Java bytecode, so it counts as a virtual machine. Similar for Rosetta.

If my understanding is right, Rosetta also uses the same dynamic translation techniques that, say, VMWare uses while the OS is running in kernel mode, so it's similar in that sense too.

Virtual machines are often viewed as software that emulates the same architecture as the underlying hardware -- the VM that VMWare provides is emulating an x86 machine -- but this needn't be the case, and the two are not necessarily all that distinct. Wikipedia says the following:

Software virtualization can be done in three major ways:

* Emulation, full system simulation, or "full virtualization with dynamic recompilation" -- the virtual machine simulates the complete hardware, allowing an unmodified OS for a completely different CPU to be run. ....

Re:Missing the point (2, Interesting)

Ngwenya (147097) | about 7 years ago | (#20821129)

I fail to see what purpose the average user has for VM technology. Sure, it's great for server systems, and as a developer I find it extremely handy, but if all you do with your computer is read e-mail, browse the web and run MS Word, why would you want a VM?


Lots of reasons: fault isolation (e.g. jail() on steroids); compatibility isolation (e.g. while most of my system runs the newest version, I keep my old apps running in a VM with an older kernel); hardware interoperability isolation (e.g. this bit of hardware is only supported in Windows, but I stick an API translator on top so I can use it from Linux with a stripped down Windows installation); virtual appliances - so that I boot my laptop only to play my DVD or check my email [without a large kernel to support it], but I want to be able to use the same application when I'm in full OS mode, so I run the app in a VM; Reliable suspension of desktop OS and associated (virtualised) peripherals. A lot of these things can be done without virtualisation - but since its now a CPU supported system, why not use a hypervisor?

Virtualisation is a useful technology in many ways - it's just deployed in different ways from use case to use case.

--Ng

Re:Missing the point (1)

Sique (173459) | about 7 years ago | (#20821631)

I am currently wondering if I should use VM to make environments for all those remote environments I have to work with. Every one asks for a different toolset, and sometimes they interfere. So having just a VM for each environment with exactly the tools needed would save me much hassle.

Re:Missing the point (1)

Deanalator (806515) | about 7 years ago | (#20822341)

Microsoft's new research operating system "singularity" http://research.microsoft.com/os/singularity/ [microsoft.com] runs every process in its own virtual machine. This way, if an attacker breaks your email client, it's MUCH more of a pain in the ass to get to the word documents.

Re:Missing the point (1)

Sloppy (14984) | about 7 years ago | (#20824347)

if all you do with your computer is read e-mail, browse the web and run MS Word, why would you want a VM?

Because the software that "average users" run, tends to be written very quickly instead of carefully. You explicitly mentioned MS Word! You just mentioned email and web browsing too, where th most popular applications have repeated histories of bugs that allow them to treat supposedly-harmless data as executable code. Hell yes those should be sandboxed to contain destruction. Maybe VMs aren't the best way to do it, but they're one of the easiest.

As far as I'm concerned, on Microsoft's platform in particular, a whole OS should be instanced every time almost any app is started. If you're not going to fix the awful UIs where clicking on a web hyperlink or email attachment can execute foreign code, then do the next best thing: limit that code to accessing to an ephemeral nothingness.

Re:Missing the point (1)

Henry V .009 (518000) | about 7 years ago | (#20821891)

You could do it in hardware. If hardware lists the hash of the binary of each VM running on the system on a niftly LCD screen, the problem goes away.

Re:Missing the point (1)

tqbf (59350) | about 7 years ago | (#20822417)

Be fair: the only researcher saying that "hypervisors can be detected, but rootkits can't" is Joanna. The rest of us, from what I can see, agree: you might not be able to detect Blue Pill by name, but you can detect unauthorized virtualization, even if you're already legitimately virtualized. Currently, the only source of unauthorized virtualization? Blue Pill.

Re:Missing the point (1)

Deanalator (806515) | about 7 years ago | (#20822427)

Also, I think Joanna was really trying to hammer the point that this was an arms race (much like signature detection vs malware at the moment). For every detection technology, there is an evasive technology to get past it, and the same is true in reverse. Detecting the current ways vrootkits are implemented really doesn't get you much in the long run.

Ah. Reactive security culture. (4, Insightful)

Chas (5144) | about 7 years ago | (#20820327)

This is undetectable*!

That is undetectable*!

* Undetectability based on current technology and the fact that nothing about a given vector of attack has been defined or studied in depth yet. Claim subject to change once the phenomenon has been studied, quantified, and dissected in a rational, forensic manner.

Translation: You can't detect it because you aren't looking for it (yet).

Translation 2: This new attack can't be defeated because nobody's tried yet!

That's what so many of these "security researchers" and pretty much ALL of the tech-press forgets.

Like any other system security compromise, the amount of time these things remain "compromising" depends largely on how long it takes to define it.

Re:Ah. Reactive security culture. (1)

skulgnome (1114401) | about 7 years ago | (#20821273)

This comment deserves a sole +5 insightful. Seriously. Demote other comments in this story if you have to.

By whom? (1)

dotancohen (1015143) | about 7 years ago | (#20820349)

Easily detectable by whom? The average grandma will _not_ be able to detect it. At what market in Vista aimed, anyway?

Re:By whom? (1)

poopdeville (841677) | about 7 years ago | (#20820387)

Easily detectable by whom? The average grandma will _not_ be able to detect it.

By grandma's malware detector.

Does this mean that The Matrix was a load of bull? (0)

demallien2 (991621) | about 7 years ago | (#20820355)

I mean, if even on our simpler computer systems, we are unable to simulate a computer well enough to hide the existence of the external simulator from the internal computer system, then it makes it a little difficult to believe that we could hide the fact that all of reality was being simulated, as in the case of the Matrix...

Or, maybe this work isn't really applicable philosophically.. Maybe they aren't describing a fundamental limit of the idea, but simply some problems with current implementations.

Re:Does this mean that The Matrix was a load of bu (1)

ensignyu (417022) | about 7 years ago | (#20820405)

Detecting the simulator requires knowledge about the simulator and the outside world. If you've always been on the inside, you wouldn't know where to look. The majority of software is not designed to know if it's living in a simulated machine (in fact, that's one of the principles of computer architecture), and maybe it's similarly true of humans.

Re:Does this mean that The Matrix was a load of bu (1)

Chrisq (894406) | about 7 years ago | (#20820563)

There are clues; Quantum randomness is caused by rounding errors.

Re:Does this mean that The Matrix was a load of bu (1)

Corporate Troll (537873) | about 7 years ago | (#20820689)

Damnit, that even makes sense.... Couldn't they use BigDecimals, no? ;-)

Re:Does this mean that The Matrix was a load of bu (1)

demallien2 (991621) | about 7 years ago | (#20820827)

Which was kind of where I was going. Quantum weirdness and the speed limit on the transmission of information both make me think of the way cellular automata function.

I was listining to a podcast the other day (Escape Pod - scifi stories), and the story was about a guy that learns that his world is in a simulator, but there are bugs, especially found in an on-line game. You can make objects leave the game and appear in the "real world".

Which brings me back to the question. We live in a "real world" which exhibits at least some of the aspects that we would expect of a simulated world, and I keep wondering what sort of programming artifacts (bugs) could exist, how could we find them, and how could we exploit them...

Anyway, I don't intend to spend my life researching answers to those questions, but they seem to me to be every bit as valid for scientific research as , for example, SETI.

Re:Does this mean that The Matrix was a load of bu (1)

Chrisq (894406) | about 7 years ago | (#20820939)

I keep wondering what sort of programming artifacts (bugs) could exist, how could we find them, and how could we exploit them...


I think that many of the bugs have been patched. For example many cultures remember a time when magic worked, enough people thinking of something with enough concentration could make it real. Some tweaks to the optimisation between the objective reality and our subjective selves sorted that out. There may be some bugs though, how often are inventions discovered by the same people at the same time, or you think of an old film to find that the guys at the TV company have thought of scheduling it!

Re:Does this mean that The Matrix was a load of bu (0)

Anonymous Coward | about 7 years ago | (#20822355)

OMG! Yesterday I was flipping through the radio stations in my car, and I found the same song playing on 2 different stations! AT THE SAME TIME!!!!

Plato (1)

jonas_jonas (1135553) | about 7 years ago | (#20824021)

Are we able to detect it [wikipedia.org] ?

VM Detectors will break on new hardware (1)

iamacat (583406) | about 7 years ago | (#20820635)

Itanium runs x86 instructions through pure software emulation
Transmeta transcodes source instructions into its native code
New versions of Intel and AMD processors and motherboards most probably will not have the same instruction timings or emulate undocumented aspects of current hardware and software
New hardware-based virtualization techniques may not change CPU performance much and can allow guest OS direct access to selected hardware

The bottom line is that VM detectors can only reliably fingerprint hardware configurations known to the developer. CPUs released a year later or ones released by smaller players like VIA will trigger false alarms and expose users to the VM/virtualization viruses since there is no way to tell the difference between trojaned and non-trojaned systems

Re:VM Detectors will break on new hardware (1)

cnettel (836611) | about 7 years ago | (#20821143)

Yeah, therefore the point would be to establish a very detailed baseline for a specific system. That way, you can analyze the exact clock skew between the sound chip and the RTC, timings for specific instructions, etc. Then, it should be possible to detect whether you are suddenly in a VM jail. To detect the jail without ever having seen anything else, that's far harder...

Homeland security? (1)

nietsch (112711) | about 7 years ago | (#20820813)

Amazing how much money your department of civilian oppression can waste on unrelated research. Yes that is right, if you RTFA, the last paragraph discloses their funding from DHS. Their subject is a noble course, but what does it have to do with the terrorists DHS were supposed to find? Or did they broaden their scope to include romanian hackers looking to make a buck?

Another concern is that this study is presented by those companies that have a stake in spreading positive news about it. And tadaa: the news is positive, VMBR's are nothing to worry about... The angle they missed is differentiating between a good and a bad VM. Strange, since they predicted that most desiable targets would be running inside VM's anyway.

Re:Homeland security? (0)

Anonymous Coward | about 7 years ago | (#20821173)

Did you actually RTFA, or just skim it and go OMG PONIES LOLZ!!. You're a fucking retard. Is DHS only about terrorists? Are they the only people planning to attack our country, and will they only use IED's? You're the finest of leftist knee-jerk slashtards.

Re:Homeland security? (1)

nietsch (112711) | about 7 years ago | (#20823421)

Yes _I_ did read it and I don't wonder if you did so yourself.
It seems I caught a nice rightwing coward that has to satisfy his righteous feelings everytime he encounters something that he thinks does not toe the party line. Anonymity + Audience => gibbering fucktard. There are other countries in the world, you know, where critical thinking is encouraged. Sadly you can't see the good points in that. But you would prefer armed citizens that can't think for themselves, don't you?

Now again: why does the DHS sponsor fundamental research in computer security? Do they think 'the terrorists' will invade the country with VMBRs? Use software based teleportation devices to bypass your 'though' borders?

BTW: I never knew the DHS was planning to attack your country, but I can imagine they would.

Is all the undetectable VM worry only theoretical? (0)

Anonymous Coward | about 7 years ago | (#20820815)

Every now and then I like to fire up a computer game. Sometimes it is one that uses three-dimensional graphics.

Correct me if I am wrong, but is it correct that at the present, any one of a number of highly paid and professional VM teams are completely unable to make a virtual machine within which I could play a three-dimensional-graphics-using-game?

So the best way of 'detecting a virtual machine' would within current technology simply be that a lot of things don't work? And the existence of a virtual machine rootkit that grandmas might be exposed to would instantly get attention because there would always be a large number of other users who would detect it straight away?

Re:Is all the undetectable VM worry only theoretic (0)

Anonymous Coward | about 7 years ago | (#20821271)

Unlike conventional host operating systems (or several guest OSs running at the same time), the root kit would have no need to access the graphics card by itself, therefore I don't see any reason why it shouldn't just allow the guest OS to directly access the graphics card.

PS:

"Slashdot requires you to wait between each successful posting of a comment to allow everyone a fair chance at posting a comment."
There are lies, damn lies, and Slashdot.

"It's been 17 minutes since you last successfully posted a comment"
Unless the typical slashdot user is a snail, that's far more than enough time to give a fair chance at posting a comment.

Tommy The Tank Engine Security (2, Interesting)

Effugas (2378) | about 7 years ago | (#20820841)

And what's Tommy the Tank Engine security?

"I think it's safe! I think it's safe! I think it's safe!" :)

Look. Virtualization is not a security technology. I've gotten a VMWare engineer to admit this publicly, on stage, with only mild needling. Virtualization reduces hardware to a protocol that must be parsed, or (as is increasingly common) it allows direct passthrough to devices on buses that have no conception of host vs. guest (see: USB).

There was actually some really cool work recently done by Jeff Forristal, who pointed out that since all VM's are on the same LAN, all the old LAN-based attacks work really well cross-VM. Oops.

Now, regarding Joanna's attack, she's completely right that everyone's going to virtualization -- it's just so much more manageable. The consumer market will eventually embrace this.

Another hacker - security war? (1)

ignatus (669972) | about 7 years ago | (#20821297)

I think the fact that a detection mechanism can be found for each vm rootkit is very plausible. However, won't rootkits always find a way to circomvent the detection mechanisms? In that case, we'll probably end up in a new hacker - security war with hackers tweaking vm's to bypass detection and security folks who keep finding new detection mechanisms. While the article clearly indicates that finding detection mechanisms is much easier than finding ways to bypass or fool the detection mechanism, it doesn't really give a sound prouf why vm rootkits won't pose a threat. The complexity of vm rootkits are indeed a drawback, but that will greatly depend on which detection mechanisms are available and how well they are implemented.

Detecting Virtual Machines (2, Insightful)

ajs318 (655362) | about 7 years ago | (#20821299)

A properly-created virtual machine ought to be absolutely undetectable from withinside. The simple fact is that all commercial offerings to date haven't tried to be undetectable.

If you lock a person in a windowless room where the only "access to the outside world" is a TV set where you control all the programmes, you essentially control everything they know about the outside world; and you then can make that person believe anything you want them to believe. You could even cause them to think night was day, if their only reference was the continuity announcer's time checks (and/or you could give them a special watch which displayed your manipulated version of the time). But if you accidentally or deliberately let, say, BBC1 get through unaltered, you aren't controlling everything they see; and by comparing the news on the real BBC1 with your altered news on the other stations, they could ascertain that something was amiss.

If your virtualised environment behaves absolutely "correctly" with respect to undocumented instructions and the like (i.e. they aren't trapped and made to do something specific to your virtualisation application), and all I/O channels are properly manipulated (to the point where even the scan line count on the graphics card is adjusted to account for the slowdown in the virtual environment), then it's undetectable from withinside. If, however, even one undocumented instruction does not behave exactly as the real processor, or even one I/O channel is left unmunged, then there is a potential way the virtual environment could be detected.

Of course, all that manipulation of stuff is bound to impose some kind of overhead, so a truly undetectable VM might end up being slow as hell ..... but on the inside, you don't know it's slow, precisely because you've been fed misinformation about the time things are taking. And processors are getting faster. They used to think that chop-and-swap analogue TV encryption would never be trivially crackable in practice .....

Re:Detecting Virtual Machines (1)

OverflowingBitBucket (464177) | about 7 years ago | (#20821363)

If, however, even one undocumented instruction does not behave exactly as the real processor, or even one I/O channel is left unmunged, then there is a potential way the virtual environment could be detected.

Malware hosting doesn't have to be perfect and hide its presence in every possible way. It just has to hide in the ways that the market-leading malware detectors use. A malware author can just set up a test system and each time the detector finds a hit, track it down and emulate around it. As you suggest, the overhead could be VERY large if it tries to catch everything. It doesn't have to hit everything. Just the bits that matter.

Of course, eventually a new technique will be added to the detector, and it'll see the malware. Then the malware gets updated, and it is invisible again. Repeat forever.

And we're not even getting into the realm where the malware host detects and reacts to these particular tests, and just alters the code being run on the guest when it spots a process that is looking for it.

Re:Detecting Virtual Machines (1)

hypnagogue (700024) | about 7 years ago | (#20824359)

You could even cause them to think night was day, if their only reference was the continuity announcer's time checks (and/or you could give them a special watch which displayed your manipulated version of the time)
Of course, by the form of your argument you have presented the weakness of your argument. All you need to test the "prisoner hypothesis" is an independent clock. Every processor, every VM, every rootkit is subject to timing tests.

Re:Detecting Virtual Machines (1)

ajs318 (655362) | about 7 years ago | (#20824849)

No it's not. Remember, you can control how many clock cycles the program on the inside thinks have elapsed. So even if it does manage successfully to ask someone else the time (by some method that would slip past your "blue pencil"), it won't have any reason to doubt the answer that comes back.

Re:Detecting Virtual Machines (1)

ceswiedler (165311) | about 7 years ago | (#20825249)

Yes, but you can compare the local CPU clock with external clocks. If the CPU claims that the timing test you execute took 2 seconds, but 20 seconds have elapsed according to an external clock, then you know something is amiss.

The external clock doesn't even have to be accessed directly. The testing app could run a test and ask the user if it seemed to take 2 seconds or 20 seconds. I don't think a CPU can skew a human's perception of time...

ta3o (-1, Troll)

Anonymous Coward | about 7 years ago | (#20821439)

share. *BSD is g.uests. Some people posts.f Due to the

Thank you, Mr. Turing. May I have another? (3, Insightful)

TrumpetPower! (190615) | about 7 years ago | (#20822331)

Folks, this is the Halting Problem [wikipedia.org] . If you have a foolproof method of detecting that you’re running in a VM, you can build a special-purpose VM that watches for that method specifically to defeat it.

Similarly, you can’t ever rule out the possibility that you yourself are living in a Matrix-style (etc.) simulated world. You might be able to detect that you are under certain circumstances, but any sufficiently advanced simulation is indistinguishable from reality. No, really!

Oh — and all this applies equally to any supposedly “omnipotent” deities you might care to propose. After all, if “God” could trap “The Devil” (to pick the current favorite pair of arch-rival gods) in a simulated world such that The Devil thought that he (The Devil) was the all-powerful creator of life, the universe, and everything ... then God has no way of knowing that The Devil hasn’t done the same to him. And if God doesn’t have any foolproof way of knowing whether or not The Devil has him trapped, and if he himself has no foolproof way of trapping The Devil, it hardly makes any kind of sense to describe God as “all-powerful,” now, does it?

Cheers,

b&

Re:Thank you, Mr. Turing. May I have another? (0)

Anonymous Coward | about 7 years ago | (#20822715)

Right now, I can trap a rock in a box, so the rock thinks it is the all powerful all knowing creator of the box.
It can do anything a rock can think of!

Since I know everything a rock can perceive, I know it can't figure out how to trap me in a box.
Replace a rock with the devil, and me with god, and you have the counter to your argument.

Re:Thank you, Mr. Turing. May I have another? (1)

TrumpetPower! (190615) | about 7 years ago | (#20823293)

An Anonymous Coward wrote:

Right now, I can trap a rock in a box, so the rock thinks it is the all powerful all knowing creator of the box. It can do anything a rock can think of!

Since I know everything a rock can perceive, I know it can't figure out how to trap me in a box. Replace a rock with the devil, and me with god, and you have the counter to your argument.

Your gods are mere pebbles beneath the Hooves of the Invisible Pink Unicorn (MPBUHHH).

And that’s the whole point, really. You can know if you’re simulating something else — of course! What you can’t know, what Mr. Turing so elegantly proved, is that you can never be certain that there isn’t something bigger than you that’s running you in a simulation.

Cheers,

b&

Re:Thank you, Mr. Turing. May I have another? (0)

Anonymous Coward | about 7 years ago | (#20824225)

The right to rule was brought in question in Eden, therefore for God to prove his right to rule he has to allow the devil to rule for a long enough period of time to prove that he cannot do so properly without god and that man cannot live without their creator's direction. If God were to trap the devil in a simulation that wouldn't be good enough because the question could then be raised again. Also, the situation in Eden was not a simulation, it was real. Therefore, the damage had already been done and creating a simulated world to fix a a damaged real one would be impractical. Finally, God would know that Satan does indeed not have the power to trap him because he both designed him and is the source of his power, limiting him from being more powerful than himself. But none of this changes the fact that your post wandered far off-topic in an attempt to derail conversations onto religion. Nice troll. Hope you're all full now.

All is fine and dandy (1)

Kickasso (210195) | about 7 years ago | (#20822937)

but what if you already run your system in a VM? What if a rootkit injects itself as another virtualization layer (at either side of your good VM)? How do you detect this sort of thing?

Malicious VMM undetectable when other VMM running (0)

Anonymous Coward | about 7 years ago | (#20823469)

Johanna did not argue that VMM are undetectable. She argued that the presence of a malicious VMM would be undetectable on a system that is running another virtual machine. The idea is that all machines will be running virtual machines in the near future, so detecting virtual machines per se will be useless.

No Security Implications (& nothing re: rootki (1)

Sloppy (14984) | about 7 years ago | (#20824185)

It looks like they're just talking about detecting if you're virtualized or not. So perhaps some of these techniques could be used by user-hostile software publishers (i.e. you're not allowed to run our server in a VM without getting a special (i.e. more expensive) license, or you're not allowed to run our media player unless we know it is directly accessing the display hardare) but I don't see how this gives any rootkit-detection advantages.

And don't ever forget: from a security standpoint, detecting malware after it's already running, is vastly distant 9th-priority tool in your arsenal, compared to more practical and obvious policies, such as not executing malware in the first place(!!!). That's what makes ideas like "blue pill" virtually (heh) insignificant when you're thinking about malware. By the time the user has already chosen to install a malware VM and then started running it, their sensitive data has already been sent to an enemy, their disk wiped, spam sent, their keystrokes logged, or whatever. Who cares about closing barn doors after the horse is out?!? Detection techniques are nearly (ok, not quite, but almost) worthless.

Oh by the way, it's a PDF (1)

Joebert (946227) | about 7 years ago | (#20824975)

I really wish Slashdot editors would place the (PDF) warning before the link.

That's undetectable! (1)

dozer (30790) | about 7 years ago | (#20825221)

"That's undetectable!"

You keep using that word... I do not think it means what you think it means.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?