3
  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):

enter image description here

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.

7
  • Nothing specific was leaked, but how Windows verfiies a signed blob can be used, was changed allowing any signed blob to virtually be used. The write up is pretty clear. It comes down to wanting to expand something originally designed not to be expanded. To be fair it's entirely possible the expansion was meant for those devices where secure boot cannot be disabled, so one could disabled, but because of a bug in the design, the vulnerability was created. The current version of Windows 10 is vulnerable
    – Ramhound
    Aug 11, 2016 at 9:58
  • They confirmed the vulnerability on Windows RT device, which is based on Windows 8 core, which means ALL versions of Windows that support Secure Boot are vulnerable
    – Ramhound
    Aug 11, 2016 at 10:03
  • This event was largely mis-reported. Have a look/listen at Security Now Episode 573. See grc.com/sn/sn-573.pdf It starts on page 4, second paragraph.
    – Marcel
    Aug 19, 2016 at 5:49
  • @Ramhound Thanks for the replies. So has this been verified to work on Windows 10 "Anniversary Edition" update? The researchers mentioned that MS did later add a security feature of some sort to Bootmgr in Win 10 that does properly check whether a secondary policy should be enforced. (Unless I misunderstood the applicability of that.) Aug 20, 2016 at 0:02
  • @halfinformed the person who found it attack Windows RT devices per my comment...did you read the explaination on the website?
    – Ramhound
    Aug 20, 2016 at 0:10

1 Answer 1

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).

10
  • This is far, far, far and away the best discussion I've read of this whole issue yet. And I've read a lot of coverage of it. Still a bit to think on, of course, but it's considerably clearer to me than it was before I read this. I do wonder if the implications for Windows 10 installs might be more significant than just making physical access scenarios more dangerous. My understanding is that a lot of the more interesting new security features are dependant on vital low-level components loading via the chain-of-trust model, with a key part of that chain-of-trust validation depending on SB Aug 19, 2016 at 23:33
  • One follow-up question: from reading the researchers's page it appears that during Windows 10 development MS did add an appropriate protection to Bootmgr in Windows 10 so that it properly verifies that only on devices authorized by MS can self-signed code be loaded under Secure Boot. Shouldn't that neutralize the applicability of this on Windows 10? Aug 19, 2016 at 23:44
  • The bootmgr of Redstone and after makes the proper verifications. But you can install an earlier bootmgr — just get an earlier beta of Windows 10 — and then you can install whatever you like. Aug 19, 2016 at 23:57
  • @Giles. Ah, sure. Duh. Aug 20, 2016 at 0:13
  • Gilles is 100% correct the golden key is a version of a file, that does something incorrectly, hence why it's being called a key. Of course its use as an attack is limit, it's primarily useful, in the sense you can do something you can't normal do with secure boot being enabled in the same sense that rooting an iPhone or Android is useful
    – Ramhound
    Aug 20, 2016 at 0:13

You must log in to answer this question.

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