virtualization.info

In this article, the last one of the first series of virtualization.info's security column (see part 1, part 2 and part 3), we will discuss how virtualization impacts high-security environments.

As we all know, virtualization vendors are marketing security as one of their main selling points. Improved manageability, a complete vision of a machine's memory and the ability to perform low-level inspection of each process are, without any doubts, killer features for any hypervisor in the security domain. 
So, should we trust vendors' claims? Should we think about virtual machines as being far "more secure" than their hard-metal counterparts?

Virtualization is not transparent at all when it comes to low level access to the CPU. Some of the functions in the CPU cannot be emulated (or it is not wise to do so), and the equivalence between virtual and physical systems is all but real when you look at this level of detail.
Of course no vendor has an interest in highlighting this aspect of the technology, and the audience doesn't seem too interested in such low-level analysis.

The reality is that this state of things has been well known for years, and security researchers have exploited the issues several times with low level attacks to virtualization infrastructures.
However, while most of these attacks are difficult to execute, to say the least, there are many issues which are much more relevant in the real world.

Let's start with a bold claim: it's very difficult, where not impossible, to perform complete hardening on virtual machines - or at least, to have a virtual machine which is as secure as a physical one - given the current state of the art in virtualization.

Hardening is a key component of what is commonly defined as "defense in depth", a complex set of security procedures aimed at mitigating the effect of an attack even when the aggressor has managed to overcome the first line of defense. Hardening a server is, generally speaking, a procedure involving multiple steps which will render the operating system and the services running on the server more secure.

This process may include improving the level of security of software configuration by applying best practices, tightening up permissions and enabling special features of the operating system. Within the Unix world, which nowadays is mostly identified with the Linux operating system, hardening a server often involves changing fundamental aspects of the system's behavior, possibly applying patches to the core component of the operating system, the kernel.

The main goal behind these procedures is making sure that even in the case of an attacker compromising one or more of the network services, the perimeter of the intrusion will be as small as possible and business impact will be minimal.

In a properly hardened server, for instance, an attacker compromising a web application would be prevented from elevating his privileges and then escalating his attack on other machines of the network, as the case would be with an unhardened server.

Even attacks leveraging critical vulnerabilities, which would result in administrative access to the machine, can be stopped when specific hardening techniques are applied, no matter whether the bug is known or unknown.

These are exactly the techniques which we are referring to when we say that virtualization has a strong impact on hardening: let's consider an example.

GRSecurity is a well known set of patches for the Linux kernel able to noticeably increase its level of security.  It is widely used in bastion hosts or public, internet exposed servers and well known to security-wise system administrators.

UDEREF is an advanced hardening feature which has been implemented in GRSecurity. While we won't go into details of how UDEREF actually works, since it would require a deep knowledge of the internals of the x86 architecture, it is a fact that the UDEREF feature is able to successfully void many Kernel level exploits - i.e. the most dangerous type of attacks, resulting in administrative access to the machine - on the Linux kernel.

UDEREF changes the way the Linux kernel handles memory segments, effectively blocking security breaches involving moving data between the so-called userland and the kernel space. Many kernel bugs can be exploited (to some extent) thanks to the way most operating systems handle the userland and kernel memory spaces.
But how does this translate into the real world, and what does it mean for a virtual environment?

Enter the vmsplice() bug.

As most Linux system administrators are well aware of, the famous vmsplice() bug is a classical kernel level attack which any local user could trivially use to escalate his privileges to root (i.e. administrative level). It was discovered in 2006 and went public quite soon, gaining popularity in the underground and being widely used in blackhat attacks.

UDEREF made exploitation through vmsplice() (and a whole class of related attacks) impossible. That is, while every Linux system was vulnerable for a certain amount of time, no hardened machine using UDEREF ever was. A huge difference when it comes to mission critical servers.

Why is this relevant? Because you can't run an UDEREF-enabled kernel as a Virtual Machine in, for example, VMware. To be more exact, you could, but performance would decrease so dramatically that it will even be automatically deactivated should it detect a VMware environment.

A similar story goes for PAGEEXEC, another feature in GRsecurity which does not work in a virtualized environment. These failures are well known to the community: the Hardened Gentoo team has a long story of testing hardened VMware guests.

Hardened Gentoo is an open source project supporting an high security distribution of the Linux operating system, which is used in bastion hosts or high risk infrastructures.

Virtualization vendors are proposing architectures which can dramatically increase the level of security of machines, possibly even detecting previously invisible rootkits online.

These features will surely change the way we think about security, but at the end of the day, until virtualization vendors can backup their claims, virtual guests simply cannot be as secure as hard-metal machines.

Labels: Security