Wednesday, November 30, 2005
Virtualizing buffer overflows
When you're done reading be sure to check out the update here.
Most people are familiar with the traditional overflow exploit methodology - find a condition where more data is sent to a buffer than the buffer can handle and gain control of program execution. With new protections against buffer overflows popping up (Stackguard, propolice, XP SP2) and better OS level protections such as randomized entry points we might be tempted to think that we're almost at the end of the road.
There's a new trend in IT that could bring buffer overflows back. Virtualization is really starting to take hold everywhere from enterprise datacenters to the desktop. In and of itself this probably isn't news to anyone nor is it necessarily very interesting. What is interesting is how virtualization might lead to a new type of buffer overflow attack.
Let's think about how a product like Vmware works. At its most basic level Vmware works by creating a virtual hardware environment including virtualized cpu, memory, disk and IO devices. Vmware offers fault tolerance and reliability by insuring that no guest operating system will have access to the resources of another guest or the host.
What Vmware and most other virtualization technologies don't seem to do is offer a lot of protections against the host modifying the virtual machines. From a design perspective this makes sense, the host needs the ability to manage and control the virtual machines and control their virtual hardware.
Putting this information into the context of buffer overflows - what if the host could modify the execution stream of a virtual machine to covertly run code? This doesn't have to happen through a buffer overflow, though that might be a fairly reliable way. Said another way, what are the implications of the host being able to modify memory and change code execution of guest virtual machines?
Think about it - the possibilities are limitless. The host could patch the running kernel by directly modifying memory on the guest. Filesystem access could be filtered at the hardware level to defeat most host based security checks. The best part about all of this is that no anti-virus or host intrusion prevention product would have a chance at detecting this. With this type of power you could create a virtual rootkit that was completely undetectable to the guest.
The reason this type of host modification should be scary is that the host is assumed to be a trusted device. Just like we trust that the motherboard and BIOS in our PC hasn't been trojaned the guest virtual machines trust the host. This seems rational but there are cases where you have secured virtual machines running on untrusted hosts. For example virtual dedicated hosting is becoming an inexpensive option through service providers such as Redwood Virtual.
There has been some work to address issues with virtual machine security. For example IBM's secure Hypervisor for the Xen virtualization tool provides some level of integrity checking for the hypervisor and the virtual machines. Here is a snippet from their documentation:
The bottom line is that all new technologies introduce security challenges and I think we're on the verge of seeing virtualization security problems hit center stage.
Most people are familiar with the traditional overflow exploit methodology - find a condition where more data is sent to a buffer than the buffer can handle and gain control of program execution. With new protections against buffer overflows popping up (Stackguard, propolice, XP SP2) and better OS level protections such as randomized entry points we might be tempted to think that we're almost at the end of the road.
There's a new trend in IT that could bring buffer overflows back. Virtualization is really starting to take hold everywhere from enterprise datacenters to the desktop. In and of itself this probably isn't news to anyone nor is it necessarily very interesting. What is interesting is how virtualization might lead to a new type of buffer overflow attack.
Let's think about how a product like Vmware works. At its most basic level Vmware works by creating a virtual hardware environment including virtualized cpu, memory, disk and IO devices. Vmware offers fault tolerance and reliability by insuring that no guest operating system will have access to the resources of another guest or the host.
What Vmware and most other virtualization technologies don't seem to do is offer a lot of protections against the host modifying the virtual machines. From a design perspective this makes sense, the host needs the ability to manage and control the virtual machines and control their virtual hardware.
Putting this information into the context of buffer overflows - what if the host could modify the execution stream of a virtual machine to covertly run code? This doesn't have to happen through a buffer overflow, though that might be a fairly reliable way. Said another way, what are the implications of the host being able to modify memory and change code execution of guest virtual machines?
Think about it - the possibilities are limitless. The host could patch the running kernel by directly modifying memory on the guest. Filesystem access could be filtered at the hardware level to defeat most host based security checks. The best part about all of this is that no anti-virus or host intrusion prevention product would have a chance at detecting this. With this type of power you could create a virtual rootkit that was completely undetectable to the guest.
The reason this type of host modification should be scary is that the host is assumed to be a trusted device. Just like we trust that the motherboard and BIOS in our PC hasn't been trojaned the guest virtual machines trust the host. This seems rational but there are cases where you have secured virtual machines running on untrusted hosts. For example virtual dedicated hosting is becoming an inexpensive option through service providers such as Redwood Virtual.
There has been some work to address issues with virtual machine security. For example IBM's secure Hypervisor for the Xen virtualization tool provides some level of integrity checking for the hypervisor and the virtual machines. Here is a snippet from their documentation:
Attestation and integrity guarantees for the hypervisor and its virtual machines.
We are extending the Trusted Computing Group (TCG) specification to include hypervisor-based server platforms. Our goal here is secure boot or authenticated boot code guarantees for the hypervisor platform, Virtual Machines, and optionally the guest operating systems and applications running on Virtual Machines. To support a large number of Virtual Machines, we have developed a virtual TPM architecture which we have applied to the Xen open-source hypervisor.
The bottom line is that all new technologies introduce security challenges and I think we're on the verge of seeing virtualization security problems hit center stage.
Comments:
<< Home
I think that the logic of the whole argument is somewhat broken or even moot.
While, encryption and/or other techniques might help to [somewhat] improve confidentiality and integrity of the virtualized environments, there is no straightforward way to protect against other problems such an attack on availability of the system.
Therefore, we have to take it as given that someone who has administrative access to a host can attack the guest causing an interruption of service.
That's does not [necessarily] mean that any efforts studying the security aspects of virtualization are fruitless, but to a degree there has to a TCB and there is no way around it.
Why do you feel that accessing a guest environment from a host resembles buffer overflows?
I'd rather say it's more like eavesdropping. That's a standard term as far as I know.
While, encryption and/or other techniques might help to [somewhat] improve confidentiality and integrity of the virtualized environments, there is no straightforward way to protect against other problems such an attack on availability of the system.
Therefore, we have to take it as given that someone who has administrative access to a host can attack the guest causing an interruption of service.
That's does not [necessarily] mean that any efforts studying the security aspects of virtualization are fruitless, but to a degree there has to a TCB and there is no way around it.
Why do you feel that accessing a guest environment from a host resembles buffer overflows?
I'd rather say it's more like eavesdropping. That's a standard term as far as I know.
In this case I was making an unstructured attempt to show the potential danger to the integrity of a virtual machine. It happened that I've been researching virtualization techniques to preserve the integrity of guests but I always find it interesting to look at the bad with the good. I haven't published any of the follow up blog entries that correspond to my research yet so that first post is more of a teaser.
So the short of my efforts is that the nature of virtual machines is such that they must compromise availability and confidentiality; but what are the implications to integrity?. Can the VMM provide integrity or can it violate it in novel ways? Are there other uses, such as live forensic analysis, where the VMM's unique view of the guest can provide new insights?
Finally the relationship I was hoping to draw between buffer overflows and virtual environments is that both have potential to inject arbitrary code into the guests execution path. I have more thoughts on this that I will be sharing publicly in the near future.
So the short of my efforts is that the nature of virtual machines is such that they must compromise availability and confidentiality; but what are the implications to integrity?. Can the VMM provide integrity or can it violate it in novel ways? Are there other uses, such as live forensic analysis, where the VMM's unique view of the guest can provide new insights?
Finally the relationship I was hoping to draw between buffer overflows and virtual environments is that both have potential to inject arbitrary code into the guests execution path. I have more thoughts on this that I will be sharing publicly in the near future.
This will be rather random..
BTW I would be happy to continue this discussion in private emails. I have an account with gmail - {$myfirstname}.{$mylastname} AT gmail D0t com
I think protecting even integrity without HW assistance might be difficult.
Let's say we are computing hashes of page content and validate that data is coherent at some checkpoints (such as pageout). We could then panic if page content was modified in a manner that raised VMM's alarm. Something along these lines… I am not sure what exactly a developer would do but usually something along these lines is done to preserve integrity. We could encrypt the info and find another way to enforce that it was not altered...
If our host is corrupt it could simply hijack this mechanism and circumvent the protection.
A shrewd attacker and a cooperating hypervisor would mean that all best are off.
To an extend host and VMM together form an OS of sorts and guests are programs. It an OS is out to get a program, what could one do? An OS has to able to write into an arbitrary memory location.
That's all IMHO.
I do not mean to flame or anything like that. I too am interested in security and virtualization, therefore I raise these questions.
The security implications of virtualization you have mentioned are real and voicing these concerns is logical.
PS Buffer overflow is not the only traditional attack that does the injection. Stack smashing too injects code. :)
Post a Comment
BTW I would be happy to continue this discussion in private emails. I have an account with gmail - {$myfirstname}.{$mylastname} AT gmail D0t com
I think protecting even integrity without HW assistance might be difficult.
Let's say we are computing hashes of page content and validate that data is coherent at some checkpoints (such as pageout). We could then panic if page content was modified in a manner that raised VMM's alarm. Something along these lines… I am not sure what exactly a developer would do but usually something along these lines is done to preserve integrity. We could encrypt the info and find another way to enforce that it was not altered...
If our host is corrupt it could simply hijack this mechanism and circumvent the protection.
A shrewd attacker and a cooperating hypervisor would mean that all best are off.
To an extend host and VMM together form an OS of sorts and guests are programs. It an OS is out to get a program, what could one do? An OS has to able to write into an arbitrary memory location.
That's all IMHO.
I do not mean to flame or anything like that. I too am interested in security and virtualization, therefore I raise these questions.
The security implications of virtualization you have mentioned are real and voicing these concerns is logical.
PS Buffer overflow is not the only traditional attack that does the injection. Stack smashing too injects code. :)
<< Home
Subscribe to Posts [Atom]