Prevention

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 [12]) 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.

Best References

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.