Virtualizing rootkits and the future of system security
Faced with the difficulty in identifying a rootkit once it has been installed, the need to safeguard and monitor the boot process and the VMM becomes critical. The admin's best approach is to avoid an infection.
From a technical point of view, the models suggested by the Trusted Computing Group (TCG ) seem like a good place to start. The key component is a Trusted Platform Module (TPM), a hardware chip that implements the TCG model on the computer's motherboard. The TPM chip provides cryptographic functions and operations, which are addressable through the BIOS and the operating system, to assess how trustworthy a system is.
On top of this, the TPM chip can be used to perform integrity checks during the boot process. To allow this to happen, special routines for critical system components calculate cryptographic hashes and store them in the TPM chip's platform configuration registers (PCRs). The corresponding evaluation instance compares the hash values calculated with the stored reference values and declares the current system configuration to be valid, permitted, or trustworthy.
Incorrect hash values indicate unauthorized changes to the system and trigger suitable responses from the evaluating instance, such as cancellation of the boot process or kernel panic. If the evaluation and the possible response occur while the system is booting, this is referred to as a secure boot. If this happens later – typically being handled by the operating system – this is referred to as a trusted boot.
These techniques allow the administrator to verify the integrity of the whole system from the boot processes to the VMM. The TPM chip and parts of the BIOS act as a core root of trust for measurement. When the system boots, the TPM chip helps the BIOS verify parts of itself and stores the hash values in the TPM platform configuration registers. After this has happened, the BIOS investigates the master boot record on the boot device and hands over control to the bootloader.
If the bootloader has been instructed to do so, it will carry on measuring values. Suitable targets are the bootloader configuration file, the initial RAM disk, the kernel file, the VMM file, and so on. If this is done consistently, the result is a chain of trust from the BIOS to the VMM. The VMM is the master of all the guest systems and can verify their integrity and respond appropriately, depending on what you want to achieve, without the guest systems influencing the process. This all sounds fine in theory, but taking care of the details can be time consuming.
To achieve a demonstrably secure boot, the reference values for each element in the chain of trust must reside in trustworthy memory. The only place to store the BIOS' checksum and hash value at the start of the train of trust is in the TPM chip's own NVRAM. Then the BIOS must store the MBR reference values in its own NVRAM, and the bootloader must have the reference values for the bootloader configuration file, and so on – the verifying instance guarantees the trustworthiness of the next link in the chain, including the reference values stored in that link.
The names of the two rootkits mentioned in this article, Red Pill and Blue Pill, are lifted from the movie "Matrix" (1999). In once scene, Morpheus (Laurence Fishburne) gives the hacker Neo (Keanu Reeves) a choice, which he has to take by swallowing either the red or the blue pill. The scene plays in an old high-rise building.
Morpheus: Unfortunately, no one can be told what the Matrix is. You have to see it for yourself. [Bends forwards towards Neo.] This is your last chance. After this, there is no turning back. [In his left hand, Morpheus shows a blue pill.] You take the blue pill and the story ends. You wake in your bed and believe whatever you want to believe. [A red pill is shown in his other hand.] You take the red pill and you stay in Wonderland and I show you how deep the rabbit-hole goes. [Long pause; Neo begins to reach for the red pill.] Remember – all I am offering is the truth, nothing more. [Neo takes the red pill and swallows it with a glass of water.] (Source )
Secure boot imposes some fairly stringent constraints on reference value management. This also means that the admin has to replace the reference values stored in the TPM chip after flashing the BIOS with new firmware, and if the bootloader codes change, the reference value in the BIOS must be changed, and so on. All of these transactions have to be secure, and this is only possible with trustworthy and authorized instances.
If an action fails, the administrator also needs some kind of backup and recovery mechanism to boot the system. And the question of whether users should be able to influence this is another hard nut to crack.
The whole infrastructure is very low level; for example, Intel's VT follows the model with its "Secure Extensions" and "Secure Boot" implementations. Because of technical complexities, production deployment of this feature on PC systems is unlikely to be worthwhile in the near future. Embedded systems, mobile phones, and PDAs, on which reference value management is easier to handle, seem more likely candidates.
A question still remains as to who the origin of trust should be: the owner of the system, the manufacturer, or even a third party? The owner is always in danger of losing control of the system because, say, a rootkit compromises all of these measures, or a manufacturer wants to dictate the software a user can install on the system.
Virtualization is increasingly making inroads into daily server operations. The virtual environment offers many security benefits through isolation and parallel contexts, but virtualization also introduces new vectors for malware.
Initial concepts impressively demonstrate how rootkits can exploit virtualization to hide malicious processes. In the future, more implementations can be expected. So far, none of these state-of-the-art virtualizing rootkits has appeared in the wild, but it makes very good sense to keep an eye on security in the virtual world.
- "SubVirt: Implementing Malware with Virtual Machines" by Samuel T. King, Peter M. Chen, Yi-Min Wang, et al. Proceedings of the 2006 IEEE Symposium on Security and Privacy, http://www.eecs.umich.edu/Rio/papers/king06.pdf
- "Red Pill … Or How To Detect VMM Using (Almost) one CPU Instruction" by Joanna Rutkowska. http://invisiblethings.org/papers/redpill.html
- Scoopy doo: http://www.trapkit.de/research/vmm/scoopydoo/index.html
- Jerry: http://www.trapkit.de/research/vmm/jerry/index.html
- IBM LPAR: http://en.wikipedia.org/wiki/LPAR
- Intel Virtualization Technology: http://www.intel.com/technology/platform-technology/virtualization/index.htm
- AMD Virtualization technology: http://multicore.amd.com/us-en/AMD-Multi-Core/Quad-Core-Advantage/At-Work-AMD-Opteron/Virtualization.aspx
- Blue Pill: http://theinvisiblethings.blogspot.com/2006/06/introducing-blue-pill.html
- Vitriol: http://www.theta44.org/software/HVM_Rootkits_ddz_bh-usa-06.pdf
- Blue Pill redesign: http://bluepillproject.org
- "IsGameOver() Anyone?" by Joanna Rutkowska and Alexander Tereshkin. Invisible Things Lab, 2007, http://bluepillproject.org/stuff/IsGameOver.ppt
- TCG: http://www.trustedcomputinggroup.org/home
- The Matrix: http://www.whysanity.net/monos/matrix3.html
Buy this article as PDF
The bug was introduced back in 2009 and has been lurking around all this time.
The new release deprecates the sshd_config UsePrivilegeSeparation option.
Lives on as a community project
Five new systems join Dell XPS 13 Developer Edition that come with Ubuntu pre-installed.
The Skype Linux client now has almost the same capabilities that it enjoys on other platforms.
At CeBIT 2017, OpenStack Day will offer a wide range of lectures and discussions.
A major setback for the Linux desktop.
Improved support for GPU in virtualization.
News site for the openSUSE community falls victim to a Wordpress exploit.
The source code is available online.