Virtual memory – the Pandora’s box?

TwitterFacebookGoogle+LinkedInRedditStumbleUpon

Every tiny detail in a virtual machine (VM) is transparent to a hypervisor because the VM is just a user space program running on it. For now, we have already heard a lot about network security, content encryption, and storage security. How about the security in virtual memory? Virtual memory is the essential component in a virtual machine. It has so many fantastic features that make it appealing. First, we could over-commit the total virtual memory allocated on the system. For instance, we could allocate 36 GB virtual memory on 32 GB physical memory because the VM usually doesn’t use 100 percent of its virtual memory. Second, VMs are able to share the same memory page if they are running the same operating system (KSM: http://www.linux-kvm.org/page/KSM). Sharing memory pages between VMs can reduce the total memory usage among all VMs, which also means that you can run more VMs on a single host.

The other fascinating characteristic of virtual memory is its transparency. There is no more hiding and there are no more secrets in virtual memory because the hypervisor owns everything now. People started thinking about how could they leverage this nice feature, and they came up with some cool ideas:

  • Process monitoring
    • We could monitor the processes running on VMs and also apply ACLs to them.
  • Registry monitoring
    • VMs that are running the Windows operating system store registries in memory, giving us the opportunity to monitor them on the hypervisor.
  • Rootkit detection
    • By monitoring SSDT and IDT on a VM, we know if the system is infected by rootkits. Moreover, we can even detect DKOM rootkit by monitoring the kernel data structure.
  • Process injection
    • Memory monitoring is so ordinary. What we can do more is to modify data stored in virtual memory. We might even inject a process in the system by modifying the memory content. This approach enforces users to run the security agent on their VM, by using process injection.
  • OS patching
    • Why do we usually need to reboot the system after applying the OS update package? Because it is how we can load the new patched kernel into the memory. From the hypervisor’s point of view, we should be able to do it without rebooting the system and the user won’t even notice it.

Is virtual memory the Pandora’s box? We can definitely use it in a good way but the rose has its thorns. Customers are also thinking the same thing. Why would they embrace the public cloud? How could they put the sensitive data in the cloud? The cloud providers know their concerns as well, so providers offered solutions to ensure data security in the cloud. All the solutions basically focus on how to encrypt the VM image and encrypt the virtual disk. In addition, they emphasize that the key is owned by the users instead of the cloud provider. Users can either store the key on their local machine or ask a trustworthy third-party to manage the key. However, what really happens is that after the VM gets the key from somewhere, it uses the key to decrypt the data, and then store the plain text data in the memory for processing. Is it difficult to recognize a pattern of credit card numbers in memory? No, it is even easier than my first programming assignment in college. Attackers and the internal thief can easily see everything in the memory, hence steal the sensitive data from the VMs. I will elaborate how simple it is to search for the credit card number in virtual memory on a KVM hypervisor in a future blog post.

The way we use the data stored on a VM is the essence of the data security issue. If you use the VM as pure storage, upload and download are the only operations you do on the VM. In this case, there won’t be any data leakage in virtual memory at all. After you encrypt the file you uploaded, and manage the key carefully, no one can steal anything from you, right? On the contrary, if we need to process the data stored on VM, we need to deal with the data security issue seriously. For example, perhaps you hosted an email server on your VM and you want to do a keyword search in the inbox. Even though you already encrypted the virtual disk, what the VM needs to do is decrypt each email and store it in memory, and then search for the keyword in memory. Anyone who can access the virtual memory on the hypervisor can easily know your secret. The same story can be applied to the accounting system running on VMs. Let’s face up to the facts, we usually need to process the data stored on VM, otherwise, how can we do cloud computing without computing?

Fortunately, we can provide data security in virtual memory by using two approaches:

  • Use new algorithms to process the encrypted data.
    • Some encryption algorithms let you search the encrypted content without decrypting it, and some of the hash algorithm can maintain the order in the original data. The main idea is that we want to decrypt the sensitive data as little as possible.
  • Leverage hardware encryption technology.
    • By using some technologies such as TPM/TXT from Intel, we can encrypt the virtual memory without affecting the performance, and even the hypervisor cannot decrypt the content in virtual memory. It will be the ultimate solution to secure you data stored in virtual memory.

Are you ready to move your applications to the cloud? Be prepared for the upcoming storm because the Pandora’s box is opened.

TwitterFacebookGoogle+LinkedInRedditStumbleUpon
Comments Off
Chenta Lee

About Chenta Lee

Chenta is the developer in ISS VSP (Virtual Server Protection) team. He is an expert in virtualization technologies and virtualization security. During the daily work, he helps people to understand the new threats in the virtual world and provide solution to their virtual infrastructure. Chenta currently lives in Taiwan, you can follow him on Twitter @ChentaLee
This entry was posted in Cloud 101, Security and tagged , , , , , , , . Bookmark the permalink.