Virtual security has some shortcomings

It's not a panacea, says Roger A Grimes

I’ve seen a spate of virtualisation products popping up to protect computers while users surf the internet. Roughly similar to Sun’s infamous Java sandbox environment, they use various mechanisms to prevent malware from infecting or modifying your computer while you browse the web, read email, or use other forms of internet-based communications (IM, p-to-p, and so on).

I’ve reviewed several of these types of products, including GreenBorder, Linux jail programs and Windows Vista’s file and registry virtualisation technology. And many of us often use Zen, VMware, or Virtual PC virtual machine sessions to safely browse the web.

While each virtualisation technology has its benefits, most of the products in this protection class share the same problems — I could mix and match my criticisms from a single spreadsheet. Here are the most commonly shared problems:

1. No sandbox product is foolproof. I’ve yet to meet one that could not be easily circumvented. So, while they might give a moderate amount of protection early on, if the sandboxes gain widespread popularity for protecting the masses, they will be hacked and circumvented. It happened to Java, and it will happen to Vista’s file and registry virtualisation protection.

I’ve been able to defeat every product I’ve personally reviewed with minimal effort. The vendors claim that their products are foolproof and don’t need constant updating “like those sorry antivirus scanning products”. Then I run a battery of malware tests, and usually a well-known worm, spambot or adware program breaks out of the virtual jail and modifies the host. Some take a bit more effort, but all have fallen within an hour of trying.

After one of my tests, one vendor that had previously claimed its product was unbreakable said, “The automated attack had simulated a manual attack, which they didn’t protect against.” Excuse me while I try to choke back the reflux!

In my Where Windows Malware Hides document, I specify more than 130 file and registry locations where malware can hide to spread in Windows. Most sandbox protection products only protect against a dozen or so file and registry locations.

All OS virtual machine products, which might be able to protect all vulnerable locations, can be detected by the bad guys and circumvented. There are a few products that perform the virtualisation outside the host; although these offer additional protection, even they can be detected — and have their own additional problems to boot.

2. Most virtual protection products don’t respond well to encoded attacks. Encoding is a popular malicious method for bypassing the initial inbound checks of a security product. Hackers and malware writers often encode malicious HTML commands into hexadecimal, double-byte, dotted decimal notation, or Unicode, instead of the ASCII text we, and protection products, expect. In many cases, the end result is that slight modifications to malicious commands are not detected or prevented.

3. Many sandbox products cover only a small subset of user applications. The vast majority cover only Internet Explorer, and maybe Outlook Express. Most don’t cover other browsers (and contrary to popular opinion, all browsers need protection), third-party email clients, IM, or other forms of internet connectivity. Why they don’t protect all internet connection traffic is a mystery to me.

4. All sandbox products prevent some small percentage of legitimate applications from installing or running. At worst, many can’t tell the difference between a Microsoft IE patch and a malware program; they simply prevent both by default. At best, they prevent most malware programs doing damage at the risk of higher false positives.

At the other end of the spectrum, some sandbox products are so secure that they don’t provide enough flexibility for consumers and end up being rewritten. For example, Java’s first security model was so secure that legitimate applications couldn’t be run or store data permanently. Sun had to modify the original security model to be more flexible, which added complexity, creating new vulnerabilities and bugs. To this day, many Java developers still use the old model, which doesn’t allow the necessary freedom that most enterprise applications need to be viable.

5. You would think that security vendors would spend an inordinate amount of time trying to ensure secure coding principles, but you would be wrong. Many, if not most, of these products contain their own vulnerabilities — buffer overflows, bugs that crash the system, hard-coded passwords, and so on. You end up trading one set of bugs for another and, of course, the program’s buffer overflow vulnerability is less likely to be exploited than IE’s.

6. Most of these security add-ons do not have enterprise deployment and management tools.

7. When the underlying OS or app is updated the sandbox or virtualisation product also has to be updated. For example, say you install IE 7 and something no longer works. Is it IE 7 or the third-party security app? You’re going to spend more time and effort looking for the true source of the problem because the sandbox won’t proactively alert you to the need for updates.

So, although sandbox or virtualisation applications provide additional security, they’re not a panacea. Nothing beats a more secure application and OS.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags securityshortcomingsDevelopment ID

More about LinuxMicrosoftUnicodeVMware Australia

Show Comments