Windows Secure Boot compromise: are fully-patched PCs vulnerable?

Question

1. Are fully-patched (as of Aug. 10, 2016) Windows installs vulnerable to allowing self-signed early-boot malware to run- because of this ? If so, which versions of Windows are vulnerable.

2. What in blazes is going on with this thing, technically? Did an actual leak from Microsoft of critical cryptographic information happen? Or is this whole thing just about the discovery of a more common security-bypass vulnerability? Something else?

3. The researchers assert that the issue is almost unpatchable, then say that Microsoft released patches in July and August had some kind of mitigatory effect. And then imply that effect may or may not prove lasting in the near future. Huh?

4. One thing I did understand from news reports and the researchers's site is that developers at Microsoft reworked something in Secure Boot as part of the continuing development of Windows 10 (ie. in 2015 and on) that led to the first existence of this problem. But multiple outlets I've seen affirm that attacks related to this work on Windows 8. Unless I missed a notice at some point about Secure Boot "improvements" being ported back to 8/8.1 in some monthly update, how is that possible? (Feel free to respond to one, some, many or all. It's a sort of hornet's nest of stuff, admittedly.)

---

Now for the long-winded explanation:

I fired up my laptop this afternoon to check the security news and saw a foreboding storyline appear on Techmeme: Secure Boot, as implemented on Windows PCs, servers, phones, and other types of devices running some flavor of Windows 8 and above, had been compromised by researchers. These systems were now once again potentially vulnerable to bootkits, rootkits, and other low-level Windows attacks that the introduction of Secure Boot in Windows 8 had done a good bit to help protect against, I particularly like the run-for-the-hills quality of this ZDnet headline (on this story):

The immediate impression I had when I started to read about the issue is that Microsoft had inadvertently disclosed some of the private keys it uses in various purposes to sign components/drivers/third-party code/etc. as secure & trusted for loading in early boot. That would indeed be a first-order debacle (ability to revoke keys or not). But as I read through takes from a few slightly, uh, calmer sources--this SecurityWeek piece seems pretty representative-- things began to look more odd. To summarize basically seem to say that:

• Instead of or in addition to secret cryptographic info being leaked, there is a security-feature bypass issue where Windows doesn't properly check whether a new type of boot policy should really be allowed to change Secure Boot behavior before basically implementing it.

• This defect was remedied before the current shipping version of Windows 10--the Windows 10 "Anniversary Edition" made available for general use on Aug. 2nd--shipped, and was never even in any previous versions of Windows to begin with. But somehow Secure Boot on every PC/device running Windows 8 & up could be affected.

• Microsoft issued two patches, in July and August, to mitigate the vulnerability. But the researchers say there's an underlying issue in Secure Boot that's basically "unfixable" without a major redesign of how Secure Boot works. (Even though the issue wasn't even present in Windows until a few months ago.) However, Microsoft's August patch might make the issue unexploitable in its current form. However however, that doesn't solve whatever that fundamental issue is.

• There are somehow polices in the researchers possession that enable them to unlock Secure Boot like "golden keys", at least on Windows RT devices.

I tried to absorb all of this information, to make some kind of coherent sense of the many contradictions and unexplained oddities contained in it. Unsuccessfully.

So, when I had some time this evening I decided I'd just go to the researchers' website and read their actual posting. (Advisory: there's an 8 bit-style soundtrack autoplaying on the page. Yeah. You may prefer to read the text from the Google cache.) Thinking and hoping that their original explanation probably contained some elements that the reported stores didn't pick up on that would let me put the pieces of what's happening here together in my head.

Nope. The news reports were largely just cut-and-paste restatements of what the researchers wrote.

(Okay, well, in fairness the researchers did outline in some detail how Microsoft created the concept of a "supplementary policy" that would allow self-signed code to be loaded and run within Secure Boot if a proper type of "legacy policy"--a conventional UEFI-variable based-policy, validated as legitimate by properly signed element--was in place to authorize it. Apparently at one point in the recent introduction of this supplementary policy concept in Windows 10 Secure Boot was not properly confirming that supplementary policies were validated against a proper authorizing legacy policy. But that was evidently fixed by MS a while ago.)

Of course, Secure Boot has never really been foolproof. But the researchers involved here essentially seem to be saying that it's going to lose most of its value as a security layer due to this problem (whatever it is), at least unless & until Microsoft substantially redesigns it.

---

Again, some actual questions:

1. Whatever the nature of the problem actually is, is Secure Boot on 32 bit & 64 bit Windows PCs running the latest release of Windows 10 for x86 (the "Anniversary Edition", released on Aug. 2, 2016) and fully-patched (as of Aug. 10, 2016) vulnerable to it?

2. What about Windows 8/8.1 for x86 (32 & 64 bit) PCs? Windows Server 2012/2012 R2?

3. What in blazes is the real nature of this problem? An actual leak from Microsoft of critical cryptographic information? A more ordinary security feature-bypass vulnerability issue? A combination of both? Something else?

4. How could a failure by MS to have in place at one point in time (ie. one point in development process of Windows 10) a sufficient security check for making sure that a new variety of Secure Boot policies were legitimately authorized cause Secure Boot to be compromised on Windows 10 even after that check was later put in place? Moreover, how could it possibly cause Secure Boot to be undermined on devices or PCs running Windows 8/8.1?

I need a drink.

Answer 1

Microsoft has inadvertently released material that allows secure boot to be bypassed. What they released was not a key in the cryptographic sense, but it's actually a good metaphor to think of it as a key in the everyday sense. Microsoft released a key that was meant to unlock certain specific doors, but it turns out that you can use this key to unlock all the doors.

The gist of booting a computer is that the hardware loads the operating system into memory and executes it. The gist of secure boot is that the hardware verifies that the operating system has been signed by the hardware manufacturer before executing it, so that only operating systems approved by the manufacturer can run.

No secret material is required on the computer. For secure boot to work, what is required is that the signature verification code cannot be modified, and that only the manufacturer can produce valid signatures. The manufacturer has a secret key which they carefully control access to, and they take care to sign only operating system images that they like.

In the real world, of course, it isn't so simple. There is a chain of several bootloaders from the CPU's initialization code to the operating system kernel. Each stage must verify that the next stage is authorized. Authorization isn't just “the manufacturer signed this”: different bootloader stages may be signed by different entities (e.g. the CPU manufacturer, the device assembler, the operating system vendor, an organization deploying a customized OS image, …). Authorizations don't just state “this OS image is authorized”, but they can have other constraints such as “this image is authorized on such and such machines” (e.g. to restrict it to an organization, or to restrict it to some testing devices). To address all the real-world requirements, Microsoft's bootloader Bootmgr makes its authorized/unauthorized decision based on multiple files: a signed code image, and also an optional set of policies.

Over time, there have been new needs for policy types, and so the policy format was extended. At some point during Windows 10 development (in the Redstone version), Microsoft released a version of Bootmgr that supported the new policy features. And they released some signed policies with the new features. These new policies contain conditions that restrict the authorization to some specific conditions.

The problem is that the older (pre-Redstone) version of Bootmgr doesn't understand the new-format conditions in the new policies, and it ends up authorizing anything. If I understand the write-up correctly (I understand the general principle but don't know how Windows's secure boot works), those policies allow anyone to define their own OS image signing key, but only on the condition that this is a test device assigned to them. But the old Bootmgr doesn't see the condition, so anybody can sign their own OS image.

This is an incompatibility between pre-Redstone Bootmgr and the new policy format. The new policy format should have been designed in such a way that older versions reject new policies, but through an oversight this wasn't fully the case. It isn't really a bug in old Bootmgr (though there may have been some bad design in that it turned out not to fail safe), but a bug in the new policies which failed to have the desired security properties when used on old Bootmgr.

There's no way to prevent the bypass devices that are already out there because anybody can grab a permissive bootmgr+policy combination and install it on their device. Newly manufactured devices could ship with a bootloader Bootmgr that blacklists all pre-Redstone Bootmgr versions, but that would mean that all existing installation media would become unusable.

Devices are affected regardless of what OS version they're running because as far as they're concerned, the permissive bootmgr+policy combination is a valid upgrade.

Of course, the talk of “panic” is completely overblown. The vulnerability is in secure boot, so it's only a concern if you're worried about evil maid attacks or if you're a vendor who doesn't like their customers running a non-approved operating system. For most users, this is irrelevant (either you control physical access and then secure boot isn't useful, or you don't control physical access and then your data is up for grabs if someone has physical access unless you used full-disk encryption).