Microsoft Will Take Nearly a Year To Finish Patching New 0-Day Secure Boot Bug (arstechnica.com) 48
An anonymous reader quotes a report from Ars Technica: Earlier this week, Microsoft released a patch to fix a Secure Boot bypass bug used by the BlackLotus bootkit we reported on in March. The original vulnerability, CVE-2022-21894, was patched in January, but the new patch for CVE-2023-24932 addresses another actively exploited workaround for systems running Windows 10 and 11 and Windows Server versions going back to Windows Server 2008. The BlackLotus bootkit is the first-known real-world malware that can bypass Secure Boot protections, allowing for the execution of malicious code before your PC begins loading Windows and its many security protections. Secure Boot has been enabled by default for over a decade on most Windows PCs sold by companies like Dell, Lenovo, HP, Acer, and others. PCs running Windows 11 must have it enabled to meet the software's system requirements.
Microsoft says that the vulnerability can be exploited by an attacker with either physical access to a system or administrator rights on a system. It can affect physical PCs and virtual machines with Secure Boot enabled. We highlight the new fix partly because, unlike many high-priority Windows fixes, the update will be disabled by default for at least a few months after it's installed and partly because it will eventually render current Windows boot media unbootable. The fix requires changes to the Windows boot manager that can't be reversed once they've been enabled. Additionally, once the fixes have been enabled, your PC will no longer be able to boot from older bootable media that doesn't include the fixes. On the lengthy list of affected media: Windows install media like DVDs and USB drives created from Microsoft's ISO files; custom Windows install images maintained by IT departments; full system backups; network boot drives including those used by IT departments to troubleshoot machines and deploy new Windows images; stripped-down boot drives that use Windows PE; and the recovery media sold with OEM PCs.
Not wanting to suddenly render any users' systems unbootable, Microsoft will be rolling the update out in phases over the next few months. The initial version of the patch requires substantial user intervention to enable -- you first need to install May's security updates, then use a five-step process to manually apply and verify a pair of "revocation files" that update your system's hidden EFI boot partition and your registry. These will make it so that older, vulnerable versions of the bootloader will no longer be trusted by PCs. A second update will follow in July that won't enable the patch by default but will make it easier to enable. A third update in "first quarter 2024" will enable the fix by default and render older boot media unbootable on all patched Windows PCs. Microsoft says it is "looking for opportunities to accelerate this schedule," though it's unclear what that would entail.
Microsoft says that the vulnerability can be exploited by an attacker with either physical access to a system or administrator rights on a system. It can affect physical PCs and virtual machines with Secure Boot enabled. We highlight the new fix partly because, unlike many high-priority Windows fixes, the update will be disabled by default for at least a few months after it's installed and partly because it will eventually render current Windows boot media unbootable. The fix requires changes to the Windows boot manager that can't be reversed once they've been enabled. Additionally, once the fixes have been enabled, your PC will no longer be able to boot from older bootable media that doesn't include the fixes. On the lengthy list of affected media: Windows install media like DVDs and USB drives created from Microsoft's ISO files; custom Windows install images maintained by IT departments; full system backups; network boot drives including those used by IT departments to troubleshoot machines and deploy new Windows images; stripped-down boot drives that use Windows PE; and the recovery media sold with OEM PCs.
Not wanting to suddenly render any users' systems unbootable, Microsoft will be rolling the update out in phases over the next few months. The initial version of the patch requires substantial user intervention to enable -- you first need to install May's security updates, then use a five-step process to manually apply and verify a pair of "revocation files" that update your system's hidden EFI boot partition and your registry. These will make it so that older, vulnerable versions of the bootloader will no longer be trusted by PCs. A second update will follow in July that won't enable the patch by default but will make it easier to enable. A third update in "first quarter 2024" will enable the fix by default and render older boot media unbootable on all patched Windows PCs. Microsoft says it is "looking for opportunities to accelerate this schedule," though it's unclear what that would entail.
Well great (Score:2, Interesting)
The NSA probably gave Microsoft instructions to slow down developing a fix for this...
So they get to use it against America's adversaries for a while longer!
Yay
Re: (Score:2)
I am America's adversary you insensitive clod.
Probably not, since you appear to be alive.
Re: (Score:1)
Just like Windows (Score:3)
Windows is always preparing to do something or telling you to wait. And here we are again.
Re: (Score:2)
What are you preparing? You're always preparing. Just go!
(And change the combination on my luggage before you do).
Impossible (Score:4, Interesting)
Re: (Score:2)
Re: (Score:2)
What will Microsoft do when malware removes the signing keys?
Require everyone buy a new machine and Windows license.
Re:Impossible (Score:5, Informative)
The proponents of "Trusted Computing" assured us that this was impossible.
The proponents of "Trusted Computing" are not incorrect. The entire UEFI boot process here is perfectly fine and they even included a mechanism of revocation that is being used in this fix to cover exactly this scenario. The issue here is revocation of keys is destructive to existing systems.
It is only a matter of time before malware like BlackLotus can replace a patched bootloader with an insecure one, and prevent a patched version from booting.
No it can't. Blacklotus isn't in control of the boot process or modifying it in any way. They are using a bug in Microsoft's shim to load a MOK key. The UEFI still loads and validates Microsoft's keys and its keys are not in any way modified or at risk.
What will Microsoft do when malware removes the signing keys?
At no point were signing keys impacted.
I think you don't really understand what is going on here, which... to be fair is incredibly sophisticated. But as far as all the Trusted Computing proponents are concerned a secure system is validating Microsoft key, and launching Microsoft's bootloader, and *AFTER THAT* a Microsoft bug allowed an attacker to take over prior to loading the kernel.
The only relevance the secure boot process has here is that fixing the bug in question requires revoking Microsoft's precious and widely used key, which is what they will be very slowly doing here.
Re: (Score:3)
The dumbshits left here have no fucking idea how the PKI system works, and what exactly is broken here.
Re: (Score:1)
Looks like they're in good company. You claim to know better but are unable to explain. Meaning you don't know any better.
PKI itself doesn't quite work, just ask Peter Gutmann [auckland.ac.nz], but it is indeed incredibly complex. As is UEFI, which is one reason why it manages to spring leaks time and again.
The summary contains a pretty good indication of the cascade of cost incurred by this gaffe, though:
Re: (Score:2)
You claim to know better but are unable to explain.
Did not does not mean unable to.
Meaning you don't know any better.
Non-sequitur.
PKI itself doesn't quite work, just ask Peter Gutmann [auckland.ac.nz], but it is indeed incredibly complex. As is UEFI, which is one reason why it manages to spring leaks time and again.
lol. Author points out well known short-comings of PKI, of which none of them have anything to do with this problem, or any of the stupid fucking comments addressing this issue. At least read your own arguments from authority.
That's a "break everything fix", that will incur considerable cost even if everyone everyehwere is quite on the ball and updates everything, at the risk of breaking legacy support which might well be business critical for settings outside vanilla bland white collar work.
Microsoft intends to revoke their key.
That has nothing to do with the soundness of PKI or a fault in UEFI.
It implies that the cost of this one gaffe may well have just wiped out all IT-department gains that UEFI, Secure Boot, and the rest of the zoo have brought. End-user gains have already been wiped out at the last gaffe.
You're a fucking idiot.
Re: (Score:2)
Re: (Score:2)
Very Informative and well written, too bad I just used my mod points
Re: (Score:2)
Maybe I didn't make it clear, but revocation of keys is exactly the scenario I was talking about. What would happen if malware was able to revoke Microsoft's signing key? Apart from (physically) replacing the system ROM, there's likely no fix, certainly not a software fix, for that scenario.
So, in essence, we are still at the same point in the 80's where a virus could erase the BIOS and brick a computer. The added complexity of Trusted Computing - while useful in preventing alternative OSes from loadi
Re: (Score:2)
Re: (Score:2)
It protects whatever the first-stage loader that the SB-enabled UEFI loads.
Ultimately, the user is in control of SB's keystore. You can remove MS' keys, if you so choose. You can whitelist hashes for specific binaries if you so choose. You can install your own CA + certs if you so choose.
Re: (Score:2)
What would happen if malware was able to revoke Microsoft's signing key? What would happen if malware was able to revoke Microsoft's signing key? Apart from (physically) replacing the system ROM, there's likely no fix, certainly not a software fix, for that scenario.
Of course there is, simply flashing the firmware. The keys aren't etched into hardware via laser, there's no hardware fuse being blown. Microsoft is literally using a mechanism here to revoke a key, does that mean that Windows will not install on any future machines? (We should be so lucky) No of course not. The keys are designed to be modifiable. Whether by malware, or fixed by a UEFI update from the vendor (which is increasingly and commonly distributed via Windows Update).
So, in essence, we are still at the same point in the 80's where a virus could erase the BIOS and brick a computer.
The goal is never to brick a com
Re: (Score:2)
This is more akin to replacing the mechanical lock on your door with a digital lock which can be circumvented by any hacker with a laptop.
While it may be true that a locksmith can't pick your digital lock, it's a moot point if anyone with a laptop can now do the same. The threat was never the rogue locksmith, but the common thief who can now more easily compromise your security.
Before "Trusted Computing", there was a time when BIOS was written into ROM. If you had physical access to the machine, and
Re: (Score:2)
The proponents of "Trusted Computing" assured us that this was impossible.
I am reminded of the following wise observation from 60 years ago. It applies, unfortunately, to many others besides "distinguished but elderly scientists".
"When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong".
- Arthur C. Clarke, “Profiles of the Future” (1962)
Moreover, just think of the profits that have accrued between that promise and today!
Re: (Score:2)
Nobody ever claimed that a protected loader could not be compromised.
In fact, that is why the revocation apparatus exists.
I am reminded of the fact that idiots on the internet commenting about shit they have zero technical knowledge of are an immutable fact of life.
wasn't secure, won't boot (Score:2)
So basically secureboot failed to deliver and now "fixing" it will make installation media, backups, imagining etc. useless.
How about they just nuke their failure, and we forget about secureboot
Re: (Score:2)
How about they just nuke their failure, and we forget about secureboot
Be sure to do it from orbit. Its the only way to be sure.
Re: (Score:1)
You clearly don't understand how Secure Boot or this attack works and just want to attack MS for no reason. Try again loser.
Re: (Score:2)
You clearly don't understand how badly secure boot is broken and how many dangerous steps the "fix" will take in coming patches, nor how it will impact with media, backups, install images and network boot systems.
In short, you are utterly ignorant of secure boot, windows, the issue here and are a loser.
Re: (Score:3)
I have "secure"-boot turned off. It does not help with my security and it stands in the way,
Re: (Score:2)
Yup. This "fix" terrifies me vastly more than any possible attack. Microsoft want us to go through this multi-stage high-risk silly-walk that, if anything goes wrong, from a company that's notorious for fscking things up during updates, the system becomes permanently bricked?
Yeah. I'll take my chances with potential malware thanks, it's far less dangerous than Microsoft's update will be.
Re: (Score:2)
No, the system isn't bricked. You always have the option to turn off SecureBoot.
Physical access or admin rights: this means you (Score:4, Insightful)
I wonder who it could be that has admin rights to your system or has physical access to your system? Could that be you, yourself or someone in your family? Nah - it must be some malicious third party that is making use of this invasive malware that magically appears on your device - but that requires physical access or possession.
Let me translate: If you own your own device or you give yourself admin rights, you can use this vulnerability. Or if you give someone else your device or you give that person admin rights, they can use this vulnerability.
First off: physical access trumps everything. Would you hand your phone to some to have them mess with it? Second. Would you give someone admin rights on your device at random?
So in the final analysis, YOU can bypass SECUREBOOT so YOU must be PREVENTED from bypassing SECUREBOOT on a device you own? A lockpick can get you into your house or it get get you burglarized. Does that mean that you need steel shutters on your house?
This is all back to making sure you CANNOT TURN OFF the THINGS the M$ and the other overlords don't want you to turn off. Rememeber the battery fiasco with iPhones where older phones were throttled but then they made the excuse that it was to protect the battery?
Never forget: secureboot is meant to be secure AGAINST YOU. No one else.
Re: (Score:2)
That seems to be at the very least lying by misdirection. Are you a Microsoft shill?
Re: (Score:2)
Exactly. Most people here are too stupid to know what's what. They're no better than Republicans that just want to make Democrats mad. People here see Microsoft and just hope for the worst outcome for them without considering all sides.
Re: (Score:2)
Let me do an extra translation for you: You are full of shit, don't understand Secure Boot, don't understand the attack, and don't understand why it has to be fixed this way.
Never forget: You are stupid and have no clue what you are talking about.
1. Very abusive (and quite unnecessarily so).
2. Completely fact-free.
3. Unpleasantly revealing of the writer's unhealthy state of mind.
Re: (Score:2)
1. Yes necessarily.
2. 100% facts about passionplay
3. State of mind: annoyed by people who think they know what they are talking about and make long winded rants that actually have no substance. The anti-MS crowd are as annoying and stupid (in their own ways) as Trump supporters.
Re: (Score:2)
Yes, pretty much. This attack can be used if your system is already compromised to keep the attack persistent, but that is it. It is not a vulnerability an attacker can use to get in.
Re: (Score:2)
All this stuff (secure boot, TPM, DRM, etc.) is for securing your system, just against you and not for you.
C'mon man, let us like, peek and poke in peace!
Not an easy answer. (Score:3)
On one hand you have "We have to close this vulnerability." On the other hand you have "Blacklisting the vulnerable binaries will make millions of USB boot sticks, Recovery CDs, Network Boot images, ISOs, and DVDs unbootable."
Do you want to rush that? Q1 2024 is only 8 months away.
The last thing they want to do is have people turn off secureboot. Rootkits sucked for everyone.
Re: (Score:1)
Re: (Score:2)
Is this finally Microsoft's checkmate move against FOSS?
If so, it looks like working about as well as Western sanctions against Russia, China, and Iran. It will backfire severely - or even fatally.
https://russia-insider.com/sit... [russia-insider.com]
https://ic.pics.livejournal.co... [livejournal.com]
Re: I'd be expecting more "Yikes!" than *crickets* (Score:2)
No impact to FOSS. First, those were signed with a different key to begin with. Second, I doubt theyâ(TM)re revoking the signing key itself, theyâ(TM)re revoking the hash of the specific vulnerable boot manager file.
If they revoked the key and started using a new one there would be the additional impact that future boot media would not boot on old systems running secure boot without knowing about the new key.
Secure boot is a fools errand (Score:2)
Much safer, easier and freedom preserving to simply write protect boot media.