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.
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?
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?
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:
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?
What about Windows 8/8.1 for x86 (32 & 64 bit) PCs? Windows Server 2012/2012 R2?
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?
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.