Slashdot Mirror
Security Threats 3 Levels Beyond Kernel Rootkits
GhostX9 writes "Tom's Hardware has a long interview with security expert Joanna Rutkowska (which is unfortunately split over 9 pages). Many think that kernel rootkits are the most dangerous attacks, but Joanna and her team have been studying exploits beyond Ring 0 for some years. Joanna is most well known for the BluePill virtualization attack (Ring -1) and in this interview she chats a little bit about Ring -2 and Ring -3 attacks that go beyond kernel rootkits. What's surprising is how robust the classic BluePill proof-of-concept is: 'Many people tried to prove that BluePill is "detectable" by writing various virtualization detectors (but not BluePill detectors). They simply assumed that if we detect a virtualization being used, this means that we are "under" BluePill. This assumption was made because there were no products using hardware virtualization a few years ago. Needless to say, if we followed this way of reasoning, we might similarly say that if an executable makes network connections, then it must surely be a botnet.'" Rutkowska says that for her own security, "I don't use any A/V product on any of my machines (including all the virtual machines). I don't see how an A/V program could offer any increased security over the quite-reasonable-setup I already deployed with the help of virtualization." She runs three separate virtual machines, designated Red, Yellow, and Green, each running a separate browser and used for increasingly sensitive tasks.
I don't use any A/V product on any of my machines (including all the virtual machines). I don't see how an A/V program could offer any increased security over the quite-reasonable-setup I already deployed with the help of virtualization.
This seems a touch... idiotic. I could see how it could offer more. AND I don't see how it could offer less.
For what its worth, I don't use an A/V product either.
And Like her, I also have a "pretty reasonable setup" and a dose of "common sense". But I'm still balancing the increased responsiveness and hassle-free experience vs the extra security. Its a trade-off that's worth it to me, but I recognize that it is still a trade-off.
She runs three separate virtual machines, designated Red, Yellow, and Green, each running a separate browser and used for increasingly sensitive tasks.
And in the article:
I totally don't care about a compromise of my "Red" machine--in fact I revert it to a known snapshot every week or so. I care much more about my "Yellow" machine. For example, I use NoScript in a browser I have there to only allow scripting from the few sites that I really want to visit (few online shops, blogger, etc). Sure, somebody might do a man-in-the-middle (MITM) attack against a plaintext HTTP connection that is whitelisted by NoScript and inject some malicious drive-by exploit, but then again, Yellow machine is only semi-sensitive and there would not be a big tragedy if somebody stole the information from it. Finally, the "Green" machine should be allowed to do only HTTPS connections to only my banking site.
And as long as your bank is never hacked and serving up malware, that probably works well...
Advice: on VPS providers
Time is only one half of the equation. What are your privacy and security worth?
I prefer rogues to imbeciles because they sometimes take a rest.
Microkernels that provide security boundaries between drivers have tended to have unacceptable levels of context switching in the kernel, so once you get past the theoretical stage and you're trying to push the performance to the point where you can compete with monolithic kernels... you're going to get rid of those boundaries.
Microkernels should be seen as a design model for a kernel, an abstraction of the traditional real-time kernel to a broader application area. You shouldn't demand or expect a microkernel to have actual separate processes for each component any more than you should or would demand a TCP/IP stack actually implement separate code layers and call gates for each level of the network stack.
It is idiotic for three reasons:
1) The vast majority of attacks out there are simple programs that install in the OS. They are not some uber VM root kits or the like. As such, a virus scanner running in the OS is perfectly capable of dealing with them. So no, it doesn't give you 100% defense but I bet it stops 99.99% of the attacks out there and that is worth something.
2) Even in the case of low level root kits, they still have to get to your system in the first place. That in general means they have to get downloaded form the net or transferred from a CD or flash drive. Guess what? A virus scanner in the OS can stop that. It can scan the program coming in, before it has a chance to run, and block it. Even if the program would set itself up on a level below what the scanner could detect, the scanner can notice it as it is coming in before it can execute and do that.
3) Defense in depth is ALWAYS a good idea. In the real, physical, world you have to accept that no security is unbreakable. Anything you can make another person can unmake or circumvent. Thus security does not come from having one impassable layer, it comes from having multiple layer of different kinds. Should one layer be bypassed, security over all is not compromised. Well, a virus scanner on the system is another layer. Should be the only layer, but it helps.
Personally, I've never been impressed with her as a security researcher. She seems to be rather paranoid, and living in a theoretical world. In part this is because for all the chatter about Blue Pill, I haven't seen it made practical. Oh sure you can talk about an undetectable super rootkit on paper but does it actually work in the real world? VMWare doesn't think it would, and they do know more than a bit about virtualization.
I'm not saying this isn't an interesting line of academic research, but I'm getting tired of the "OMG I can own any system and not be detected!" doomsaying. No, really, not the case it seems.
Most of your time IS worth nothing. But people are too arrogant to admit it.