I've been learning about UEFI Secure Boot. It is designed to prevent malware from infecting the boot process and overwriting the bootloader. It has hardware-level protections to ensure that only a signed, trusted bootloader and OS kernel will be loaded and executed upon boot.

Today, malware can overwrite the Master Boot Record (MBR) with a malicious version, so that every subsequent boots into an evil version of the operating system. UEFI Secure Boot would prevent that, because your machine will only run the bootloader if it is signed, and the attacker's modified bootloader won't have a valid signature. In other words, with UEFI Secure Boot, you should be confident that, once you reboot, you're now running a valid and trusted bootloader and OS kernel. Sometimes people summarize this by saying that UEFI Secure Boot prevents "bootkits". OK, the basic concept makes sense.

I want to understand what stops the following sort of attack. Suppose you are running Windows (for example). Suppose the attacker, who has gotten malware on your machine and wants to ensure he'll stay resident after reboots, modifies the Windows startup configuration to launch a virtual machine (VM). Inside the VM is a modified Windows image -- just like a standard Windows kernel and OS and image, basically a full copy of what is on your machine, except that the kernel has been modified to plant some malware into it. When you boot, this VM is automatically launched, and (suppose) it automatically starts up in full-screen mode.

It seems like this attack subverts the intended goals of UEFI Secure Boot. From the user's perspective, it feels like they are running Windows, in their full desktop environment. What they don't realize is that their entire environment has been infected with malware. Sure, the host operating system is trustworthy (thanks to UEFI Secure Boot), but the guest operating system (within the VM) is malicious, and the user has no obvious way to tell that they are interacting with an evil guest rather than with the host. So, the user will think everything is OK, when actually they are hosed. Connoisseurs of security concepts will recognize this as an attack on "trusted path": the computer booted a trustworthy kernel, but the user has no way to verify that they are interacting with a trustworthy kernel rather than an entirely untrustworthy "evil twin".

Does anything prevent this attack? Or, is this attack technically feasible? If it is feasible, does it violate the security goals or threat model behind UEFI Secure Boot? (More generally, does anyone have a precise statement of the security goals and threat model underlying UEFI Secure Boot, and exactly what it does and doesn't guarantee?)

1 Answer 1


The attack you describe sounds more like a "diamond heist" attack of sorts (a bit elaborate for the everyday criminal). Before I address UEFI, I wanted to answer if that is feasable. No, not really. If we are talking about a server running a VM, the end user may not notice a performance issue (given enough physical resources) but more than likely the monitoring software in place would detect a new process running and a system administrator would respond. A good sys admin would hopefully be able to tell once he investigates.

If it were a desktop user, he would most likely notice very quickly when he reboots his machine and it looks a bit different. Assuming the VM could spoof the old desktop, the hardware installed, and not display information about the VM running, he may be fooled.

But I think the question was more about the technology than the individual, so my thought would be yes, it appears this type of attack would work for the reasons you stated: the host OS is trusted and secure boot loaded that OS. The VM process could be hidden inside of another process (svchost, maybe?) and both user and monitoring tools could be fooled (for a time).

Your last question (what it does and doesn't guarantee) I found some information at the home page http://www.uefi.org/home/ for UEFI. The answer to the question, "What is UEFI" states:

UEFI (Unified Extensible Firmware Interface) will be a specification detailing an interface that helps hand off control of the system for the pre-boot environment (i.e.: after the system is powered on, but before the operating system starts) to an operating system, such as Windows* or Linux*. UEFI will provide a clean interface between operating systems and platform firmware at boot time, and will support an architecture-independent mechanism for initializing add-in cards.

From this answer, I believe you are promised nothing. UEFI is a framework that vendors and coders can implement. I believe it would be up to the vendors and coders to make the guarantees.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .