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.

Comments

Re:Better solution: read only media

[Enleth]

Been there, done that, works great.

A few years ago, I set up a bunch of thin clients for general browsing, chatting and homework at a school dorm - they were (were, as I have no idea if they're still in use, but they were absolutely maintenance-free, so I guess they should be) running Linux, with the kernel and boot config (generated on the fly) loaded from a read-only TFTP server and / mounted from a read-only NFS share. On each boot, the init scripts would finish generating a machine-specific configuration in /etc/ and mount a few ramfses on top of some directories using unionfs to give an illusion of a read-write filesystem. Then, upon login (LDAP authentication), the user's directory would be mounted from an individual password-protected Samba share (accessible from the users' personal computers as well), with the noexec attrubite of course. /tmp/ and /var/ were also noexec. Upgrades to the client system were performed at the server, by chrooting into the exported root directory.

Such a configuration is absolutely invulnerable to users, rootkits, viruses and any other riffraff known for breaking things in computers. Even in the unlikely event that someone gained root privileges on a client, they would actually gain nothing and even that nothing would vanish after a reboot.