Virtualization Decreases Security

ParaFan writes "In a fascinating story on KernelTrap, Theo de Raadt asserts that while virtualization can increase hardware utilization, it does not in any way improve security. In fact, he contends the exact opposite is true: 'You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.' de Raadt argues that the lack of support for process isolation on x86 hardware combined with numerous bugs in the architecture are a formula for virtualization decreasing overall security, not increasing it."

Comments

Useless

[andreyw]

Theo's side keeps asserting that "x86 virtualization isn't secure", but they seem to be perfectly comfortable at keeping the discussion at the level of a "I'm right, NO I'M RIGHT", without any corroborating statements (Hint: Theo's "I am familiar with x86 and its 'nastiness'" isn't one). What's not secure about SVM? What's not secure about VT-x? Why does Theo think that virtualizatio somehow has to imply legacy PC I/O emulation?

Ugh.

Re:Useless

[Krondor]

What's not secure about SVM? What's not secure about VT-x?

VT-x and SVM provide paths for rootkits to integrate and hide. New rootkits like Blue Pill and Vitriol utilize SVM and VT-x to virtualize the host platform and remain undetected and immune from removal. They're not widespread, but an attack vector exists, which implies the security concerns over them.

Makes sense to me.

I'm Not Sure I Buy His Analysis

[Nova Express]

The snippet presented seems to suggest that more security holes in virtualization = less secure operating system, or OS(X) + V(X), where OS(X) represents the operating system vulnerabilities and V(X) represents virtualization vulnerabilities.

However, I see this more as if the virtualization layer actually sits under the OS layer, then the actual security for remote intrusion would be, first, Y/OS(X), THEN Y/V(X), where Y is the number of people with the knowledge to exploit each vulnerability. Thus, someone who wanted to exploit the system would both have to be capable of exploiting an OS vulnerability, and THEN also exploiting a virtualization vulnerability.

(And we're talking about remote usage, because we all know it's virtually impossible to protect a system from anyone who has direct access to the hardware.)

I understand that reality may not be quite as tidy, but it still seems like a virtualized system would be much more secure that a non-virtualized system, if only because the increased level of knowledge involved means a smaller number of hackers capable of exploiting both layers. What am I missing?

Security == managing complexity

[kscguru]

Virtualization is NOT intended for security. Period, end of story, full stop. Security is a secondary effect from having smaller interfaces, and you DO get smaller interfaces with inherent security advantages.

Here's the first truth of security: your ability to secure a system is INVERSELY PROPORTIONAL to the size of the interface to that system. Every interface point is a potential attack vector, whether direct (an attacker can exploit the interface) or indirect (something outside your control is loaded at interface A, then an attacker at interface B causes A to exploit something). Most security products try to reduce the size of interfaces (e.g. a firewall limits the number of open ports, then further excludes some types of traffic from those ports).

Look at a general purpose operating system kernel. There are hundreds of system calls (direct attack vectors), hundreds more driver interfaces (indirect attack vectors - driver interfaces are privileged and thus drivers must be bug-free), a few thousand more configuration points (Windows Registery, Linux /sys and /proc trees). Add the libraries that make up the rest of the operating system, and the number of APIs has exploded to thousands, if not tens of thousands.

Now look at a hypervisor stack. The hypervisor::guest interface is the CPU instruction set (extremely well documented and easy to programatically verify, especially when 99% of instructions can be verified to have no side effects!). Much narrower interface than a general-purpose API. The driver::hypervisor interface is narrower too, since the hypervisor only uses a lower-level interface (e.g. Xen's block device interface, VMware's SCSI interface) that happens to be simpler and better documented. Configuration API is smaller, since it only needs to manage virtual machines, not every possible combination of user-level program and device.

It's the old microkernel / monolithic kernel debate all over again, where a hypervisor is a microkernel and a general-purpose OS is a monolithic kernel, and the performance loss is small enough that companies are using it in production today. Microkernel have advantages in being easier to secure, more robust in the face of bugs ... monolithic kernels are faster. Is the smaller API (and increased security) worth the loss in performance?

Here's some security thoughts, based on actual experience with virtualization bugs.

• The largest number of security vulnerabilities appear in user-level servers, e.g. NAT, DHCP, ssh, apache. Potential commands to these services are unlimited (wide API), often involve text-parsing in C code (inherently difficult), and so they are hardest to secure.
• A moderate number of security vulnerabilities appear in paravirtualized device emulations. Paravirtual devices are less well specified (medium-width API), so the implementations have more bugs, often from ways the paravirtual device spec doesn't anticipate. (Yes, hardware folks write more complete specs than software folks).
• Extremely few security vulnerabilities appear in the hypervisor::guest boundary. This boundary is extremely well specified via data sheets and architectural manuals. (narrow API).