Seven shortcomings of virtual security

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

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell TEST CENTER DAILY BLOG Track the latest product reviews and news from the InfoWorld Test Center.

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

While each virtualization 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 you 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 virtualization protection.

I’ve been able to defeat every product I’ve personally reviewed with minimal effort. The vendors often claim that their products are foolproof and don’t need constant updating “like those sorry anti-virus 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 successful malware tests, a vendor that 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 be circumvented. There are a few products that perform the virtualization 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, maybe Outlook Express. Most don’t cover other browsers (and contrary to popular opinion, all browsers need protection), third-party e-mail 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 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 that their products use 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. Although the program's buffer overflow vulnerability is less likely to be exploited than IE's, of course.

6. Most of these security add-ons do not have enterprise deployment and management tools. If the virtualization application isn’t updated, is the same amount of protection still there, or has a new hole opened up?

7. Virtualization applications also complicate support and troubleshooting events. When the underlying OS or app is updated, the sandbox or virtualization product often has to be updated as well. For example, say you install IE 7 or Firefox 2.0 and some previously functioning application or Web site no longer works. Is it the new browser or is the third-party security app not working with the browser?

So, although sandbox or virtualization applications provide additional security, don't begin to believe they are a panacea. Nothing beats a more secure application and OS.