I'll quote the grandparent: If these guys had made it CLEAR that they were using a NON-APPLE network device from the get-go we wouldn't be having this discussion today.
And I'll quote my reply: the researchers did, in fact, make it clear that they were using a non-Apple network device. It was in the talk. It was in the video
I'm well aware of what they said. That doesn't change the fact that HIS post implied that they hid the fact that their exploit demo was with third-party equipment. I don't know if he implied it out of ignorance (perhaps having not watched the video) or because he is a vehement Mac fanboy (I happen to love the platform, myself, I just don't think it's the end-all be-all of security), but the fact remains that he were wrong in his statements and I called him on it.
Ultimately, it boils down to this: Apple claims that there is no vulnerability, implying that the proof is in the video. This is not the case, as the video explicitly states that it's a third party card/driver. Apple's reasoning for this being Not Their Problem is spin.
So the researchers say there is a vulnerability. They provide no proof. Apple says that there is no such vulnerability. They provide no evidence that they've researched it, only an explanation that the video isn't all that the blogs make it seem to be.
This is a non-news story until someone makes a stronger, more supported statement.
Just because the driver is VERY heavily used doesn't mean it's immune to bugs. If no one's looked for it (pretty reasonable idea, considering OS X's market share) then it may have lain dormant for a long time. Hell, look at Microsoft's WMF bug existed all the way back to Windows 3.1, but was only discovered this past year.
Remember, we're talking about attacking the device driver here. By far, more people attack, probe, fuzz, etc. at the application layer. It's not outside the realm of reason to believe that buffer overflows (for example) exist in device drivers, which are probably less scrutinized for this type of bug.
As for the "leverage".. maybe Apple just requested that they not release/show it and they agreed. It's not outside the realm of reason.
1) The researchers faked the demo in order to gain reputation. They refuse to release the source because there is no source.
This really doesn't seem likely. Apple isn't claiming that there is no flaw, just that the Airport isn't flawed. It's really quite reasonable to assume that there could be a remote-code execution bug in a driver.
2) The researchers lied when they said that the Airport has a vulnerability, too. Apple is telling the truth when they say there is no flaw.
I think this is not necessarily valid for two reasons.
1) Apple stands to lose a lot more than the researchers have to gain. The researchers gain credibility for discovering a remote-code execution bug in an Apple product--big deal. There have been other remote-root bugs in Apple products. Do you remember any single person who discovered it? Do you even remember the flaws? Apple is building a reputation for being rock-solid and secure, but it's pretty unreasonable to believe that there are NO remote code executions in their products.
2) Other people have seen and reported on the flaw. They could be in on the hoax, or they could have been duped by a faked live demo, but that's stretching the conspiracy theory pretty far. More likely is that Apple's PR guy is set to "deny mode until the devs have confirmation" and the devs just haven't confirmed anything yet.
These guys were not caught lying. They state in the video that it's a third party driver. Stop spreading FUD.
Your claim that you "don't know what the exploit was" and then give that crazy scenario really only proves that you don't know anything about the presentation they gave. They explicitly stated that they turned on the ability to connect to any access point so that they could get a remote shell, however if that feature wasn't on, they'd still be capable of delivering a payload to the remote machine.
The speakers were discussing the "Next Big Flaw." Most "Next Big Flaws" are somewhat overstated. Their "Next Big Flaw" is in wireless device drivers, because they are remote and because device drivers in general are often rushed and not as well checked for security problems as applications. Their claim was that they wanted to bring this out before we start much longer-range wireless devices become more commonplace.
I spoke with them after their talk at Blackhat and asked for more specifics. According to them, there are flaws in the most common wireless devices. They couldn't get remote code execution on all of the flaws, but they could at least get a crash. It's possible that a more carefully constructed exploit/could/ give remote code execution in the crash cases.
My suspicion is that the Airport card+driver resulted in a crash. That's not really as spectacular or newsworthy as remote code execution, so they used a wireless card+driver which had that particular flaw. A crash is still a problem and could still eventually lead to remote code execution. It's just not as sexy.
This also explains why they (allegedly) were talking with Apple about the flaw--the flaw they disclosed to Apple may not have been remote code execution, but a remote kernel panic.
It kills me that you were modded insightful, because the researchers did, in fact, make it clear that they were using a non-Apple network device. It was in the talk. It was in the video. Anyone who paid attention to what they were saying and not to all the hype would have clearly known the circumstances of the vulnerability.
I'll back you up on this, with a caveat: they claimed that every OS had drivers that were susceptible, and they claimed that Apple was no exception. They also chose to demo it on an Apple because they wanted to shake up the "Apple is more secure" myth (they said as much in the Blackhat talk). I don't remember for sure if they explicitly stated that the Airport itself contained this flaw--only that this flaw was exploitable on Apple. That could very well mean that the Airport is not vulnerable, but that the drivers for third-party cards are. If I'm misremembering, please correct me.
They were trying to make it look like the Mac platform isn't a bulletproof-defense against malware, no doubt. They also/did/ state that they were working with Apple, which makes it sound more like an Apple problem than a third-party problem. There is no doubt in my mind that they were trying to spin this. That said, they are right. Macs are just as vulnerable to bad programming as any other platform.
There's a really, really legitimate reason for not doing the demo live: they'd basically be releasing the exploit. After all, they were giving the talk to a large room full of people with notebooks, and if they started doing a demo, you know damn well that at least a fourth of them would start a wireless packet capture.
I know how to fix the timings on Linux. Unfortunately, I rarely need to run Linux in Qemu:) Usually I emulate Windows, on which there is no solution that I'm aware of.
And I'm afraid I may have to eat my earlier words. Just grabbed the latest snapshot (I was using a release from June or so) and there is definite improvement. I couldn't even get kqemu working with this snapshot, but still Qemu is working much better than I suggested earlier (I'm about halfway through the WinXP install process, so I'm going to remain just a little skeptical until I'm actually in Windows). Hopefully I'll see this sort of performance boost when using it on FreeBSD, too.
I'm glad someone said it. The VM solution solves hardware problems, though. With VMs set up in this way, you don't have to worry about workstation hardware failing--if it does, just give them another computer configured to load the VM, and they're off. With ghosting, the hardware can still fail, and your image might not work on the next piece of hardware (this is mitigated if all the machines in your company are identical, but even then, some incompatibilities can arise because often the guts of two identical models will differ). The poster specifically mentioned HAL incompatibilities, so I'm guessing there's some sort of problem there. Nevertheless, I do think that the VM solution is trading these problems for a lot of management/performance issues down the road.
Of course, the poster shouldn't expect to get around Windows/software problems with this method. If the user is allowed to download and install software, they'll still get infected, unstable installs all the time, and they'll still have to revert to clean images (the equivalent of reinstalling) periodically. A really wacky solution would be to use this VM idea combined with user profiles stored on a separate server so that reinstalls don't hurt so much. That's getting really complicated, though.
Everyone goes on and on about how great QEMU is, but frankly, I think it's almost useless on Linux. The free VMWare solutions are faster and more stable by orders of magnitude (with or without the kqemu kernel module) if you need a full Windows environment, and for other emulation applications, there are generally better solutions like Wine or the various DOS emulators.
QEMU is painfully slow even on a beefy machine and with the kernel module. IO with qcow is pretty bad, too (it's tolerable with raw disk access). I also usually have terrible clock skew and timing problems (cursor blinks really fast, keyboard repeat rate is absurdly short or long, etc), none of which I have with VMWare.
The only reason I ever stick it out with QEMU is when I'm on a FreeBSD desktop, and that's only because QEMU is the only free emulator that I know of for FreeBSD that even comes close to correctly handling Windows XP.
Please don't suggest it for Linux when there are much better, free (as in beer) options available.
I've never heard anything about Symbian being based on PalmOS. Even if it was, it's obviously got enough modifications to allow multitasking. Try that trick on a Treo 650 or 700p and see if you get the same results.
I wasn't aware that a software virtualizer could pass all instructions directly on to the hardware such as the video card. Nevertheless, I don't know of any that do it, and thus even if my statements aren't accurate from a technical standpoint, they appear to be accurate from a pragmatic standpoint.
Is it possible (in software) to replace the OS with a virtualized one, passing all but privileged instructions to the hardware, and trap certain key instructions to be handled by your virtualizer, all while the OS is still running?
I chose Windows Mobile primarily for its ability to multitask. Specifically, I want to be able to maintain an SSH connection while I'm switching to another app to look something up. That is something that Palms cannot handle at this point.
We keep hearing promises from PalmOne that they'll have a multitasking version of the OS out "soon", but it never seems to happen. I used a phone with a broken screen for almost a year, betting (wrongly) that Palm would have their solution out. They never did, and I went with the PPC6700 from Sprint (running Windows Mobile 5.0).
I'm not unhappy, but that's about all I can say about it. It's an adequate OS, but it has quirks. I'd probably sell it in a heartbeat if a Palm solution came out which met all my needs.
The problem is that you're thinking of software virtualization rather than hardware virtualization (as in the Core Duo chips and AMD's newer chips). Both of your cases outlined above are dealt with using the instruction sets in these chips.
1) The hardware is the same unless the hypervisor changes what the software sees. All the hardware in the device manager will look just like it did pre-virtualization. This was demonstrated at Black Hat.
2) This is simply not true with hardware virtualization. It may be difficult to do, but Blue Pill was demonstrated through a video file as not requiring a reboot to initialize the VM with the running OS's settings. Furthermore, a live demonstration (first attempt crashed, though the second attempt was successful) on a Macbook showed that this was possible without a reboot.
What you have to realize is that this is all very new stuff on bleeding edge processors. It will be years before the majority of CPUs in homes will have this capability. For most users, what you say above is true--but not with these new chips.
An excellent idea, however if AV companies start doing this, what will BluePill++ start doing? Blocking NTP? Blocking whatever ports the AV software uses to chec the external time? Is the AV software's inability to function necessarily indicative of BluePill, or could there be something else wrong?
This is a whole new battlefield, and while (as I've said before) I don't think this is the doomsday exploit that some people are claiming it is, I think it's something to be taken seriously if you're concerned about security.
You're talking about two different types of VMs. #1 applies to software VM (like VMWare) and #2 applies to hardware virtualization.
That said, I don't recall making claim #1 at all, so I don't know what you're talking about or why you bring it up. Even if a virus could detect that it was running in a VM, unless it could escape the VM, it still would be contained.
If I understand your method correctly, it still requires the use of an external clock. If that's the case, there's still no programmatic way to do it, you're still relying on external sources, which is something your average end-user is unlikely to do.
The paper was presented at Black Hat. She explained what is required in order to fully "emulate" the instructions required to make it undetectable. Essentially, Blue Pill would need a shim that passes virtualization instructions back up the chain until they could be executed for real, then return everything back down. It's not as huge as everyone thinks, but it's not trivial, either. But yes, she's outlined what has to be done.
I bet you can find a PDF of her slides somewhere online, if you're interested.
Right. As has been said, "undetectable" means "from within the VM itself". You're also talking about prevention, which is equally important. TPM could also prevent virtualization-based exploits, already exists in a fairly convenient form, is more robust (doesn't require an external server which could be down or bogged down), and fits in fairly well with corporate culture.
I think that it would be impossible to provably show that a complete Blue Pill implementation is on your system from within that system. The idea being, it might be possible to detect anomalies by using software on the infected VM. It would be impossible to definitively say "You are infected with Blue Pill." The most it could do is say, "I found X, Y, and Z timing/instruction anomalies which lead me to believe that I am running in a VM. User, am I running in a VM to the best of your knowledge?" This is assuming that timing isn't programatically modified (possible), instructions aren't perfectly emulated (possible), and that the user doesn't think to check for clock skew (highly possible).
Undetectability has to be put into context. A livecd should be able to detect signs of malware on a system just fine. Using non-computer metrics (such as stopwatch-based timing) might also detect anomalies, if you have a pre-infection benchmark to compare it to. Sniffing on your LAN should detect any traffic sent out by your box that shouldn't be there. This doesn't make it detectable from within the running, infected system.
She admitted that timing attacks were her weakness, as did the other guy who talked about virtualization-based rootkits. The problem is that you have to have a benchmark to compare it to, and you have to assume that the hypervisor doesn't modify the time whenever it is called. If the time does get modified, then the only way we know of to detect the rootkit is to measure clock skew on the infected PC using a real time source. This, of course, assumes that there isn't any real clock skew, or you get a bunch of false positives.
All of this requires a full implementation of Blue Pill, though, including the ability to virtualize "within" the virtualized OS. That is something that will be awhile coming--then again, mass adoption of CPUs which can handle virtualization will be awhile coming, too.
When people talk about Blue Pill as being "undetectable" they mean "through the use of a program."
And that's Joanna's point. Properly constructed, Blue Pill 2 (the successor with full emulation support coded in--she herself admitted that her prototype is imperfect) would be undetectable by software running inside the VM. She discusses the possibility of a timing attack using an external clock, but also notes that this is infeasible in a large deployment. Certainly it would be infeasible for your average person running a computer (evidence by the fact that some of them don't even run antivirus/antimalware programs at all and get horribly infected!)
I was at Joanna's Black Hat briefing. Not once did she imply that this was Vista specific--in fact, she mentioned another briefing with the same sort of rootkit--only running on a MacBook. Her briefing was entitled "Subverting the Vista Kernel for Fun and Profit" because the first half of her talk was about elevating privileges in Vista, which would allow a rootkit such as Blue Pill to run.
I think that the danger here lies somewhere between "The end is very fucking nigh" and "This is absolutely nothing to worry about." Yes, it's extremely hard to implement. But that shouldn't mean we don't worry about it, because one implementation and it will be much easier to reverse engineer/modify to do other nasty things. Also, the eventual inability to detect in software means that if such an attack ever comes to pass, it will be extremely difficult to clean en masse (virtually requiring a reinstall or a livecd).
Slashdot Mirror
I'll quote the grandparent:
If these guys had made it CLEAR that they were using a NON-APPLE network device from the get-go we wouldn't be having this discussion today.
And I'll quote my reply:
the researchers did, in fact, make it clear that they were using a non-Apple network device. It was in the talk. It was in the video
I'm well aware of what they said. That doesn't change the fact that HIS post implied that they hid the fact that their exploit demo was with third-party equipment. I don't know if he implied it out of ignorance (perhaps having not watched the video) or because he is a vehement Mac fanboy (I happen to love the platform, myself, I just don't think it's the end-all be-all of security), but the fact remains that he were wrong in his statements and I called him on it.
Ultimately, it boils down to this: Apple claims that there is no vulnerability, implying that the proof is in the video. This is not the case, as the video explicitly states that it's a third party card/driver. Apple's reasoning for this being Not Their Problem is spin.
So the researchers say there is a vulnerability. They provide no proof.
Apple says that there is no such vulnerability. They provide no evidence that they've researched it, only an explanation that the video isn't all that the blogs make it seem to be.
This is a non-news story until someone makes a stronger, more supported statement.
Just because the driver is VERY heavily used doesn't mean it's immune to bugs. If no one's looked for it (pretty reasonable idea, considering OS X's market share) then it may have lain dormant for a long time. Hell, look at Microsoft's WMF bug existed all the way back to Windows 3.1, but was only discovered this past year.
Remember, we're talking about attacking the device driver here. By far, more people attack, probe, fuzz, etc. at the application layer. It's not outside the realm of reason to believe that buffer overflows (for example) exist in device drivers, which are probably less scrutinized for this type of bug.
As for the "leverage".. maybe Apple just requested that they not release/show it and they agreed. It's not outside the realm of reason.
There are two issues to consider here:
1) The researchers faked the demo in order to gain reputation. They refuse to release the source because there is no source.
This really doesn't seem likely. Apple isn't claiming that there is no flaw, just that the Airport isn't flawed. It's really quite reasonable to assume that there could be a remote-code execution bug in a driver.
2) The researchers lied when they said that the Airport has a vulnerability, too. Apple is telling the truth when they say there is no flaw.
I think this is not necessarily valid for two reasons.
1) Apple stands to lose a lot more than the researchers have to gain. The researchers gain credibility for discovering a remote-code execution bug in an Apple product--big deal. There have been other remote-root bugs in Apple products. Do you remember any single person who discovered it? Do you even remember the flaws? Apple is building a reputation for being rock-solid and secure, but it's pretty unreasonable to believe that there are NO remote code executions in their products.
2) Other people have seen and reported on the flaw. They could be in on the hoax, or they could have been duped by a faked live demo, but that's stretching the conspiracy theory pretty far. More likely is that Apple's PR guy is set to "deny mode until the devs have confirmation" and the devs just haven't confirmed anything yet.
These guys were not caught lying. They state in the video that it's a third party driver. Stop spreading FUD.
Your claim that you "don't know what the exploit was" and then give that crazy scenario really only proves that you don't know anything about the presentation they gave. They explicitly stated that they turned on the ability to connect to any access point so that they could get a remote shell, however if that feature wasn't on, they'd still be capable of delivering a payload to the remote machine.
The speakers were discussing the "Next Big Flaw." Most "Next Big Flaws" are somewhat overstated. Their "Next Big Flaw" is in wireless device drivers, because they are remote and because device drivers in general are often rushed and not as well checked for security problems as applications. Their claim was that they wanted to bring this out before we start much longer-range wireless devices become more commonplace.
/could/ give remote code execution in the crash cases.
I spoke with them after their talk at Blackhat and asked for more specifics. According to them, there are flaws in the most common wireless devices. They couldn't get remote code execution on all of the flaws, but they could at least get a crash. It's possible that a more carefully constructed exploit
My suspicion is that the Airport card+driver resulted in a crash. That's not really as spectacular or newsworthy as remote code execution, so they used a wireless card+driver which had that particular flaw. A crash is still a problem and could still eventually lead to remote code execution. It's just not as sexy.
This also explains why they (allegedly) were talking with Apple about the flaw--the flaw they disclosed to Apple may not have been remote code execution, but a remote kernel panic.
It kills me that you were modded insightful, because the researchers did, in fact, make it clear that they were using a non-Apple network device. It was in the talk. It was in the video. Anyone who paid attention to what they were saying and not to all the hype would have clearly known the circumstances of the vulnerability.
I'll back you up on this, with a caveat: they claimed that every OS had drivers that were susceptible, and they claimed that Apple was no exception. They also chose to demo it on an Apple because they wanted to shake up the "Apple is more secure" myth (they said as much in the Blackhat talk). I don't remember for sure if they explicitly stated that the Airport itself contained this flaw--only that this flaw was exploitable on Apple. That could very well mean that the Airport is not vulnerable, but that the drivers for third-party cards are. If I'm misremembering, please correct me.
/did/ state that they were working with Apple, which makes it sound more like an Apple problem than a third-party problem. There is no doubt in my mind that they were trying to spin this. That said, they are right. Macs are just as vulnerable to bad programming as any other platform.
They were trying to make it look like the Mac platform isn't a bulletproof-defense against malware, no doubt. They also
There's a really, really legitimate reason for not doing the demo live: they'd basically be releasing the exploit. After all, they were giving the talk to a large room full of people with notebooks, and if they started doing a demo, you know damn well that at least a fourth of them would start a wireless packet capture.
I know how to fix the timings on Linux. Unfortunately, I rarely need to run Linux in Qemu :) Usually I emulate Windows, on which there is no solution that I'm aware of.
And I'm afraid I may have to eat my earlier words. Just grabbed the latest snapshot (I was using a release from June or so) and there is definite improvement. I couldn't even get kqemu working with this snapshot, but still Qemu is working much better than I suggested earlier (I'm about halfway through the WinXP install process, so I'm going to remain just a little skeptical until I'm actually in Windows). Hopefully I'll see this sort of performance boost when using it on FreeBSD, too.
Thanks for the tip. Hopefully Qemu holds up!
I'm glad someone said it. The VM solution solves hardware problems, though. With VMs set up in this way, you don't have to worry about workstation hardware failing--if it does, just give them another computer configured to load the VM, and they're off. With ghosting, the hardware can still fail, and your image might not work on the next piece of hardware (this is mitigated if all the machines in your company are identical, but even then, some incompatibilities can arise because often the guts of two identical models will differ). The poster specifically mentioned HAL incompatibilities, so I'm guessing there's some sort of problem there. Nevertheless, I do think that the VM solution is trading these problems for a lot of management/performance issues down the road.
Of course, the poster shouldn't expect to get around Windows/software problems with this method. If the user is allowed to download and install software, they'll still get infected, unstable installs all the time, and they'll still have to revert to clean images (the equivalent of reinstalling) periodically. A really wacky solution would be to use this VM idea combined with user profiles stored on a separate server so that reinstalls don't hurt so much. That's getting really complicated, though.
Everyone goes on and on about how great QEMU is, but frankly, I think it's almost useless on Linux. The free VMWare solutions are faster and more stable by orders of magnitude (with or without the kqemu kernel module) if you need a full Windows environment, and for other emulation applications, there are generally better solutions like Wine or the various DOS emulators.
QEMU is painfully slow even on a beefy machine and with the kernel module. IO with qcow is pretty bad, too (it's tolerable with raw disk access). I also usually have terrible clock skew and timing problems (cursor blinks really fast, keyboard repeat rate is absurdly short or long, etc), none of which I have with VMWare.
The only reason I ever stick it out with QEMU is when I'm on a FreeBSD desktop, and that's only because QEMU is the only free emulator that I know of for FreeBSD that even comes close to correctly handling Windows XP.
Please don't suggest it for Linux when there are much better, free (as in beer) options available.
I've never heard anything about Symbian being based on PalmOS. Even if it was, it's obviously got enough modifications to allow multitasking. Try that trick on a Treo 650 or 700p and see if you get the same results.
I wasn't aware that a software virtualizer could pass all instructions directly on to the hardware such as the video card. Nevertheless, I don't know of any that do it, and thus even if my statements aren't accurate from a technical standpoint, they appear to be accurate from a pragmatic standpoint.
Is it possible (in software) to replace the OS with a virtualized one, passing all but privileged instructions to the hardware, and trap certain key instructions to be handled by your virtualizer, all while the OS is still running?
I chose Windows Mobile primarily for its ability to multitask. Specifically, I want to be able to maintain an SSH connection while I'm switching to another app to look something up. That is something that Palms cannot handle at this point.
We keep hearing promises from PalmOne that they'll have a multitasking version of the OS out "soon", but it never seems to happen. I used a phone with a broken screen for almost a year, betting (wrongly) that Palm would have their solution out. They never did, and I went with the PPC6700 from Sprint (running Windows Mobile 5.0).
I'm not unhappy, but that's about all I can say about it. It's an adequate OS, but it has quirks. I'd probably sell it in a heartbeat if a Palm solution came out which met all my needs.
I'm not really sure what you're talking about. The last time I saw it in action, DVDShrink would handle CSS for you.
The problem is that you're thinking of software virtualization rather than hardware virtualization (as in the Core Duo chips and AMD's newer chips). Both of your cases outlined above are dealt with using the instruction sets in these chips.
1) The hardware is the same unless the hypervisor changes what the software sees. All the hardware in the device manager will look just like it did pre-virtualization. This was demonstrated at Black Hat.
2) This is simply not true with hardware virtualization. It may be difficult to do, but Blue Pill was demonstrated through a video file as not requiring a reboot to initialize the VM with the running OS's settings. Furthermore, a live demonstration (first attempt crashed, though the second attempt was successful) on a Macbook showed that this was possible without a reboot.
What you have to realize is that this is all very new stuff on bleeding edge processors. It will be years before the majority of CPUs in homes will have this capability. For most users, what you say above is true--but not with these new chips.
An excellent idea, however if AV companies start doing this, what will BluePill++ start doing? Blocking NTP? Blocking whatever ports the AV software uses to chec the external time? Is the AV software's inability to function necessarily indicative of BluePill, or could there be something else wrong?
This is a whole new battlefield, and while (as I've said before) I don't think this is the doomsday exploit that some people are claiming it is, I think it's something to be taken seriously if you're concerned about security.
Simple.
You're talking about two different types of VMs. #1 applies to software VM (like VMWare) and #2 applies to hardware virtualization.
That said, I don't recall making claim #1 at all, so I don't know what you're talking about or why you bring it up. Even if a virus could detect that it was running in a VM, unless it could escape the VM, it still would be contained.
If I understand your method correctly, it still requires the use of an external clock. If that's the case, there's still no programmatic way to do it, you're still relying on external sources, which is something your average end-user is unlikely to do.
Or do I misunderstand?
The paper was presented at Black Hat. She explained what is required in order to fully "emulate" the instructions required to make it undetectable. Essentially, Blue Pill would need a shim that passes virtualization instructions back up the chain until they could be executed for real, then return everything back down. It's not as huge as everyone thinks, but it's not trivial, either. But yes, she's outlined what has to be done.
I bet you can find a PDF of her slides somewhere online, if you're interested.
Right. As has been said, "undetectable" means "from within the VM itself". You're also talking about prevention, which is equally important. TPM could also prevent virtualization-based exploits, already exists in a fairly convenient form, is more robust (doesn't require an external server which could be down or bogged down), and fits in fairly well with corporate culture.
I think that it would be impossible to provably show that a complete Blue Pill implementation is on your system from within that system. The idea being, it might be possible to detect anomalies by using software on the infected VM. It would be impossible to definitively say "You are infected with Blue Pill." The most it could do is say, "I found X, Y, and Z timing/instruction anomalies which lead me to believe that I am running in a VM. User, am I running in a VM to the best of your knowledge?" This is assuming that timing isn't programatically modified (possible), instructions aren't perfectly emulated (possible), and that the user doesn't think to check for clock skew (highly possible).
Undetectability has to be put into context. A livecd should be able to detect signs of malware on a system just fine. Using non-computer metrics (such as stopwatch-based timing) might also detect anomalies, if you have a pre-infection benchmark to compare it to. Sniffing on your LAN should detect any traffic sent out by your box that shouldn't be there. This doesn't make it detectable from within the running, infected system.
It was quite an amazing talk, wasn't it?
She admitted that timing attacks were her weakness, as did the other guy who talked about virtualization-based rootkits. The problem is that you have to have a benchmark to compare it to, and you have to assume that the hypervisor doesn't modify the time whenever it is called. If the time does get modified, then the only way we know of to detect the rootkit is to measure clock skew on the infected PC using a real time source. This, of course, assumes that there isn't any real clock skew, or you get a bunch of false positives.
All of this requires a full implementation of Blue Pill, though, including the ability to virtualize "within" the virtualized OS. That is something that will be awhile coming--then again, mass adoption of CPUs which can handle virtualization will be awhile coming, too.
Why do you think that the size of the app would "take days to download"?
When people talk about Blue Pill as being "undetectable" they mean "through the use of a program."
And that's Joanna's point. Properly constructed, Blue Pill 2 (the successor with full emulation support coded in--she herself admitted that her prototype is imperfect) would be undetectable by software running inside the VM. She discusses the possibility of a timing attack using an external clock, but also notes that this is infeasible in a large deployment. Certainly it would be infeasible for your average person running a computer (evidence by the fact that some of them don't even run antivirus/antimalware programs at all and get horribly infected!)
I was at Joanna's Black Hat briefing. Not once did she imply that this was Vista specific--in fact, she mentioned another briefing with the same sort of rootkit--only running on a MacBook. Her briefing was entitled "Subverting the Vista Kernel for Fun and Profit" because the first half of her talk was about elevating privileges in Vista, which would allow a rootkit such as Blue Pill to run.
I think that the danger here lies somewhere between "The end is very fucking nigh" and "This is absolutely nothing to worry about." Yes, it's extremely hard to implement. But that shouldn't mean we don't worry about it, because one implementation and it will be much easier to reverse engineer/modify to do other nasty things. Also, the eventual inability to detect in software means that if such an attack ever comes to pass, it will be extremely difficult to clean en masse (virtually requiring a reinstall or a livecd).