X
Tech

Google: Beware virtualization, GreenBorder NO security panacea

Google: Beware Virtualisation, GreenBorder NO Security Panacea
Written by Donna Bogatin, Contributor

In Google vs. Symantec, McAfee? Not exactly earlier today, I underscored that, contrary to popular perception, Google's recent acquisition of start-up software security firm GreenBorder Technologies does not signal impending doom for the two category leaders.

What IS the BIG deal? A simple Google buy versus build technology decison for security software does not a sector killer move make, I noted.

What's more, the technology iteself that was acquired is NOT the security panacea it is popularly perceived to be.

Does GreenBorder’s software really create an impenetrable protective barrier that can be considered a DMZ Demilitarized Zone?

Can a free consumer software download really be expected to deliver security miracles?

NO, at least not according to Google's own evaluation of the security limitations of virtualization, offered from any vendor:

Virtual machines are often used by security researchers to sandbox malware samples for analysis, or to protect a machine from a potentially hazardous activity. The theory is that any security threat or malicious behaviour will be restricted to the virtual environment which can be discarded and then restored to pristine condition after use.

Virtual machines are sometimes thought of as impenetrable barriers between the guest and host, but in reality they're usually just another layer of software between you and the attacker. As with any complex application, it would be naive to think such a large codebase could be written without some serious bugs creeping in. If any of those bugs are exploitable, attackers restricted to the guest could potentially break out onto the host machine.

There are a number of ways that an attacker could break out of a virtual machine, Google asserts and identifies:

Most of the attacks identified were flaws, such as buffer overflows, in emulated hardware devices. One example of this is missing bounds checking in bitblt routines, which are used for moving rectangular blocks of data around the display. If exploited, by specifying pathological parameters for the operation, this could lead to an attacker compromising the virtual machine process. While you would typically require root, or equivalent, privileges in the guest to interact with a device at the low level required, device drivers will often offload the parameter checking required onto the hardware, so in theory an unprivileged attacker could be able to access flaws like this by simply interacting with the regular API or system call interface provided by the guest operating system.

Google has evaluated the security exposure to hosts of hostile virtualized environments to conclude that as virtual machines become increasingly commonplace as a method of separating hostile or hazardous code from commodity systems, the potential security exposure from implementaion flaws has increased dramatically.

What's more, Google has found that virutal machines are not robust enough to withstand vigorous testing and present multiple expolitable flaws that could allow an attacker restricted to a virtualized environment to reliably escape onto the host system.

Google's bottom line: Because virtualization is NO security panacea, treat virtual machines as services that can be compromised.

Why has Google acquired virtualization play GreenBorder then? Why not?

As I analyzed earlier today in Google vs. Symantec, McAfee? Not exactly, Google's acquisition strategies and motives are as varied as its deals.

Google may want to use GreenBorder as a virtualization testing ground. OR, rather than providing Google a key piece of technology, GreenBorder may offer one particularly compelling proposition:

Unlike virtualization software from rivals requiring multiple Windows licenses for each corporate user, GreenBorder insulates the Microsoft Windows system from the underlying computer hardware and only requires a single license for Windows, according to Neil MacDonald.

Editorial standards