Microsoft patches Windows to eliminate Secure Boot bypass threat
- Thread starter JournalBot
- Start date
Yay centralized trust run by a sclerotic company focused on <checks notes> .. todays AI hype cycle !
Where’s a buffer overflow hallucination generating Copilot AI when you need one , amirite?
Where’s a buffer overflow hallucination generating Copilot AI when you need one , amirite?
Upvote
49
(58
/
-9)
That's pretty novel. And a little scary.
Makes me wonder if checking and cataloging .efi files should be part of our client management. It would certainly be worth checking if installed .efi files are on a whitelist (and if not, client is flagged as in breach of policy).
Makes me wonder if checking and cataloging .efi files should be part of our client management. It would certainly be worth checking if installed .efi files are on a whitelist (and if not, client is flagged as in breach of policy).
Upvote
26
(26
/
0)
- Add bookmark
- Featured
- #4
If you are interested in checking your systems (Windows or Linux), you can follow the guidelines from WeLiveSecurity.com.
Last edited:
Upvote
58
(58
/
0)
Wasn't it the same with device drivers? When they started pushing for signed drivers, a ton of shitty/buggy/blue-screen-inducing drivers were approved.
I don't think you can expect every single thing that gets signed by MSFT to be thoroughly and expertly vetted, unfortunately.
I don't think you can expect every single thing that gets signed by MSFT to be thoroughly and expertly vetted, unfortunately.
Upvote
38
(38
/
0)
Maybe there is not "Microsoft’s UEFI third-party code-signing review", they simple code-signing the files the UEFI manufacturer give then without review.
Upvote
23
(23
/
0)
What is the point of a chain of trust if you can't trust the entity holding the signing keys is actually vetting things? Or even trust them to revoke a maliciously-obtained signature in a timely fashion?
Upvote
66
(66
/
0)
- Add bookmark
- Featured
- #8
Uggh. I just ran these on my win 10 & win 11 systems, both are showing vulnerable (first check) and unprotected (driver is not revoked). And Windows Update has nothing for me--on either system. I guess we just wait? Some more?
Upvote
29
(29
/
0)
Vetting things costs money and requires qualified personnel. =)
edit: and reduces shareholder value.
Upvote
25
(26
/
-1)
I don't mind the idea of a chain of trust between UEFI and OS, but the implementation leaves any OS without a giant corporate backer out in the cold, which itself leads to less secure computers if they happen to be running such an OS. I do like how some implementations allow importing a signature into the secure boot system, but not all do yet, and doing so is far more clunky than "it just works" Windows. (Take however many pinches of salt you need for the part in quotes.)
What gets me is that this had to be solved with an OS patch, which suggests software workarounds are an inevitable problem for it in the future. While I will still be using this on servers that exclusively run Windows, just for that little bit of extra security, at the end of the day considering a system already needs to be compromised, this is mainly a threat of making that compromise harder to remove.
What gets me is that this had to be solved with an OS patch, which suggests software workarounds are an inevitable problem for it in the future. While I will still be using this on servers that exclusively run Windows, just for that little bit of extra security, at the end of the day considering a system already needs to be compromised, this is mainly a threat of making that compromise harder to remove.
Upvote
9
(10
/
-1)
Mine is showing "true" for both.
So, I guess that I am vulnerable yet not vulnerable...
Upvote
5
(5
/
0)
Mine is showing Variable is currently undefined: for both. So... me too?
Upvote
5
(5
/
0)
Upvote
22
(22
/
0)
The OS update is likely just going to be to add new entries into the UEFI secure boot dbx database, which lists the hashes or public keys of things which are not allowed to be run even if they are properly signed. It's basically a revocation list, but for EFI executables.
Microsoft can easily do this for Windows. But so can every major Linux distribution or any other non-Windows OS. This capability is built into the UEFI secure boot mechanisms and standards.
Upvote
15
(15
/
0)
My system refuses to accept 24H2, there are no other updates, and the command posted above returns false. BTW, thanks for posting that script, awesome person.
Upvote
9
(9
/
0)
I feel like I'm missing something; but can anyone clarify how exactly a Windows update solves the problem?
Is there a defined and required mechanism for UEFI firmware to ingest a suitably signed updated db/dbx file from a location available to both the OS and the firmware(presumably the EFI partition)?
If there isn't an ingest mechanism, and the file just gets read from the EFI partition, what prevents a downgrade attack? I assume that you can't just put a random, unsigned, file in the correct format in the location and tell the firmware to trust me bro; but it's not like older, MS-signed, db and dbx files are a secret; every computer that got updated this month had copy until quite recently.
I can see how it would work if there was also a motherboard firmware update released but(while windows supports delivering UEFI capsule updates) Microsoft does not do those except for surface devices or when vendors choose to make their own firmware updates available on WU; but I'm failing to understand how any OS-level change on top of unpatched firmware would be in a position to survive a downgrade attack.
Is there a defined and required mechanism for UEFI firmware to ingest a suitably signed updated db/dbx file from a location available to both the OS and the firmware(presumably the EFI partition)?
If there isn't an ingest mechanism, and the file just gets read from the EFI partition, what prevents a downgrade attack? I assume that you can't just put a random, unsigned, file in the correct format in the location and tell the firmware to trust me bro; but it's not like older, MS-signed, db and dbx files are a secret; every computer that got updated this month had copy until quite recently.
I can see how it would work if there was also a motherboard firmware update released but(while windows supports delivering UEFI capsule updates) Microsoft does not do those except for surface devices or when vendors choose to make their own firmware updates available on WU; but I'm failing to understand how any OS-level change on top of unpatched firmware would be in a position to survive a downgrade attack.
Upvote
3
(4
/
-1)
My house is completely unaffected by lock picking. It doesn't have any locks! /s
Upvote
24
(26
/
-2)
I can't believe it. I'm absolutely gobsmacked.
microsoft still have an internal review process?
microsoft still have an internal review process?
Upvote
6
(10
/
-4)
I think you'll find that feature is nothing to do with MacOS itself but of the Apple designed and built, proprietary hardware, something Apple control which makes these things very simple to implement.
Microsoft and Linux (which is also garbage by your judgement) do not have the luxury of one set of hardware but has to work on hardware that can be used for any OS that wants to run on it and can be made (well or badly) by multiple manufacturers with varying degrees of security.
Having said that many server vendors have implemented similar pre-boot environments that allow installing firmware updates, hardware management and OSes installs over the network.
My last Windows install took me 10 minutes from boot to all configured including addition software and updates (and bloat removal). But I guess you have to know what you are doing on your weapon of choice.
Upvote
22
(22
/
0)
Ignoring the rest of the comment, the statement was "...the vulnerability made it possible for attackers who had already gained privileged access to a device to run malicious firmware during bootup..."
So attackers who gain privileged access to the OS running on a device can use that access to install software which will then run on every subsequent boot.
Upvote
13
(13
/
0)
Basically every system with secure boot enabled will show 'true' for the first check. It's not entirely accurate to say that makes you vulnerable to this*.
*: defining 'this' as the specific vulnerable bootloader.
A more accurate check:
Code:
$UEFI2011CertInDB = [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Corporation UEFI CA 2011'
$UEFI2011CertInDBx = [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Corporation UEFI CA 2011'
$UEFI2011CertTrusted = ($UEFI2011CertInDB -and (-not $UEFI2011CertInDBx))
$Vulnerable64BitBootloaderBlocked = [BitConverter]::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'
$Vulnerable32BitBootloaderBlocked = [BitConverter]::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'
If ( $UEFI2011CertTrusted ) {
If ( -not $Vulnerable64BitBootloaderBlocked ) {
Write-Output "Your system trusts the vulnerable 64-bit bootloader from CVE-2024-7344"
} else {
Write-Output "Your system does not trust the vulnerable 64-bit bootloader from CVE-2024-7344"
}
If ( -not $Vulnerable32BitBootloaderBlocked) {
Write-Output "Your system trusts the vulnerable 32-bit bootloader from CVE-2024-7344"
} else {
Write-Output "Your system does not trust the vulnerable 32-bit bootloader from CVE-2024-7344"
}
} else {
Write-Output "Your system does not trust the 'Microsoft Corporation UEFI CA 2011' cert, so your system does not trust either of the vulnerable bootloaders from CVE-2024-7344"
}Now, on to too much detail about why this is going to be a major fustercluck to really remediate:
It does not seem that most UEFI firmwares can handle dual-signed bootloaders. So any given bootloader can only be signed by the older 2011 cert, or the newer 2023 cert.
And we already know of SO MANY vulnerable bootloaders signed by one of the 2011 certs (there are vulnerable Windows bootloaders too, not just third-party ones) that we can't add all their hashes to the DBX.. the storage space isn't large enough. <InsertLaugh/Cry emoji here>
So, microsoft has to move everyone to using the newer 2023 certs. This isn't a huge deal on systems that are already installed and running. But the big gotcha comes when you need to reimage the systems: Your Windows (or Linux) install media uses a bootloader signed by one of the two. Old or new, not both.
If Microsoft just wanted to get this fixed ASAP, and released a windows update that enrolled EVERYONE's UEFI with the 2023 Certs (which they are going to do, if they haven't already*), and then also had code that would revoke the 2011 certs (adding them to the DBX in the local firmware)... well, these would all be fixed.
But next time you need to reimage the system, or use the firmware update disk from your hard drive manufacturer, or whatever... if that isn't updated to a bootloader that has been signed by the 2023 certs, you'll have to disable secure boot to run it. Maybe that isn't a big deal for the individual home user, but this is going to be a major hassle for IT departments everywhere. Especially if they restrict the firmware admin passwords, so the average tech who could plug in their imaging USB key and reimage can't just go in and disable it themselves.
And if you have something like what I have: A usb key with bootable rescue tools on it.. again, its primary bootloader can only be signed by either the old cert or the new one. So you're going to probably keep the old cert as long as possible, but eventually switch to the new cert.. hopefully before microsoft revokes the old certs.
*: Note, that KB article claims it started rolling out last year. But I have yet to see a system enroll the 2023 certs automatically (until maybe today - I have a Microsoft Surface that I don't think had the 2023 certs a few weeks ago, but does today.. but it still trusts the 2011 cert just fine as well).
Upvote
12
(12
/
0)
I have this update installed, but I'm failing all the checks using the scripts posted here.
Upvote
0
(0
/
0)
Yes, there is a defined process for updating the db or dbx databases, it is defined in the UEFI spec and such database changes are protected by the KEK or PK keys. See UEFI spec 2.11 section 32.5.3 (page 1550) for details. The EFI system partition is not a part of the process, you directly manipulate EFI variables which most modern operating systems expose and can interact with.
Upvote
4
(4
/
0)
I believe you CAN output a signed update file, and load it from a UEFI shell from the EFI System Partition (ESP) or any other partition the EFI firmware can read (some OEMs have paid for an NTFS and/or exFat license so they can add a driver to read those partition types too). I believe this is how I did it when adding my own cert to the PK on a system I was doing some secure boot work on. I then used a similar file to add the cert to the DB, by signing it with the cert I added to the PK, and using a linux utility to load the signed 'update' file.
Windows has a service that reads their dbx updates and applies them to the firmware. Since Microsoft has a cert in the KEK, they can sign updates with that cert and your firmware will trust them. You can see the event log messages related to this process here.
Upvote
3
(3
/
0)
Fair question. This is deregulation - MSFT has to trust the vendor. There's probably a little dance the vendor has to go through - name rank serial number, maybe even an ISO certification. MSFT probably has some automated tools they run looking for known issues, and the rest is "is this a known entity?" and if so they stamp it Approved!
There's a chain. They vetted it. I doubt it's a full code review though, or pen-test like.
Upvote
3
(3
/
0)
They messed something up because I haven't been able to login to Microsoft Todo on my Mac since Tuesday. Keeps saying it's been disabled for my account. I can use all other Microsoft apps. Outlook did make me sign in, but I was able to do that without issue.
Upvote
-10
(0
/
-10)
There IS a code review, but they offload it to third parties:
https://techcommunity.microsoft.com/blog/hardwaredevcenter/updated-uefi-signing-requirements/1062916
Basically, at this point: They only expect to approve/sign third party UEFI bootloaders from one of two code lineages:
And they look at your branch of the code, to make sure you haven't done anything stupid since you branched from upstream, and want you to use a HSM of some variety to hold your signing key, and some other sanity checks.. but most of this is done by either the shim developers or the ipxe developers, not microsoft. If that group approves, I bet microsoft does some static analysis and makes sure the binary you handed them for signing matches what gets built by the actual source code you claim it was from, and then they sign it.
I wouldn't be surprised if large OEMs have ways of getting other things signed, but when it comes to random open source/small company stuff, it basically has to be a fork of one of the two above.
As for why they need to sign different branches.. in the case of shim, one of the key features of shim is that a linux distro can embed their own signing key in their copy of shim, so that they can sign their grub/kernels with their own keys, instead of requiring microsoft to sign them. Shim also supports checking against the keys and hashes in DB/DBX, but the main point of using shim is, for example, Ubuntu embeds the public cert for their code signing cert, then gets microsoft to sign that version of shim. So when you boot an ubuntu disk, their shim is signed by microsoft, but has an additional cert it uses to validate grub and the kernel.
iPXE is a little different, and doesn't allow embedding extra certs that I know of, so there's less reason to use a custom compiled version of it, but a software vendor went through the hoops of getting it signed a little while ago so they could use it in their software.
Upvote
2
(2
/
0)
Thank you! Much better version. Below is the confirmation from my computer running Windows 11 Pro Workstation
Your system does not trust the vulnerable 64-bit bootloader from CVE-2024-7344
Your system trusts the vulnerable 32-bit bootloader from CVE-2024-7344
Upvote
2
(2
/
0)
Yep, I finally got one of mine to apply the dbx update as well, and it reports the same.
This may be 'correct' - in that the 32-bit vulnerable bootloader would pass a secure boot check... but most PCs don't support 32-bit UEFI boot, so you could never actually boot it... so microsoft didn't use up space in your DBX blocking a file it would never be able to boot.
Upvote
5
(5
/
0)
Upvote
0
(0
/
0)
calumnious
Seniorius Lurkius
3 days later, still no available patch included on the latest Insider Preview Canary build 27774.1000.
It's frustrating the bleeding edge images are somehow behind on Security Updates, and sometimes even features. Microsoft needs to get their act together across the offered channels. Just gonna re-enroll my keys and block everything else in the meantime, I guess.
Anyone in the same boat who would like to temporarily disable third-party bootloaders not signed by Microsoft:
It's frustrating the bleeding edge images are somehow behind on Security Updates, and sometimes even features. Microsoft needs to get their act together across the offered channels. Just gonna re-enroll my keys and block everything else in the meantime, I guess.
Anyone in the same boat who would like to temporarily disable third-party bootloaders not signed by Microsoft:
bcdedit /set {bootmgr} flightsigning offbcdedit /set nointegritychecks off
Upvote
0
(0
/
0)
Ubuntu (and most major distros) work out of the box with SecureBoot
Upvote
1
(1
/
0)