-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Warn if media will no longer be bootable after Q1 2024. #2244
Comments
Yikes... Do I get that right, any official ISOs past a given date will be good, then? |
Aha, I was wondering how long Microsoft would try to swipe that CVE under the carpet until they had no choice but to take action.
Yeah, that's the major issue here. Microsoft have some kind of revocation list, but of course, they didn't make it downloadable as a standalone (because, why would they? Security through obscurity has always worked WONDERS for everybody....), so it's going to be a PITA.
I'll try to do that. But I'm not going to rush into it, and spend time that I don't have being a trailblazer. So I'm going to tag this as deferred for now. |
Sounds good! I mean there's essentially an entire year to work on this |
Looks like checking for
|
I saw the registry key, but I don't think it's enough, because it only tells if the current machine might have been upgraded to reject old MS bootloaders, but not if the ISO contains one. In other words, if we only check for the registry key, we will warn the user regardless of whether the ISO they selected uses an old or new bootloader, whereas we obviously don't want to warn about ISOs that use the new bootloaders. So, again, to properly display the warning, we need to check the bootloader's hash against the revoked hashes. From my understanding, the registry key is just a switch to tell the system to update the UEFI revocation list with the hashes of the old bootloaders since, understandably, Microsoft does not yet want to apply revocation wholesale and leave users booting older Windows ISOs facing a Secure Boot validation error. They only want to do that for users who opt-in. Now, another potential workaround I am considering, provided we can actually download the new bootloaders from Microsoft's servers without having to extract a whole ISO (the issue being that I can't just store a copy of these bootloaders on a server somewhere for Rufus to download, without committing copyright infringement, so we have to hope that they're in a small enough The problem with this workaround however is that this would potentially only work for the initial USB boot (pre-installation phase) and not for the post file-copy (re)boot, as my current assumption is that during initial file copy, Microsoft picks the bootloaders from I am obviously planning to test this when I have a chance (which may not be before a couple of month or worse) and when I have upgraded a system to the new revoked hashes (which I will need to do carefully and make sure to keep a copy of the revocation list before and after, since I need to isolates these bloody hashes that Microsoft SHOULD provide publicly but, no matter where I looked so far, doesn't!)... |
https://uefi.org/revocationlistfile |
Aha! Since we're talking about an upcoming revocation, and Microsoft is the sole entity that controls the revocation list, I didn't think they would have started to add DBX entries prior to Q1 2024, since it means that we're definitely going to see Secure Boot validation errors with Windows media long before that date (because motherboard manufacturers are not going to cherry pick what goes in the DBX they apply but pick the most recent). Their process to decide whether a bootloader should be flagged as vulnerable or not is less than straightforward though, per https://uefi.org/sites/default/files/resources/dbx_release_info.pdf:
So, we do not have a complete list of hashes of vulnerable bootloaders, and we're going to have deal with this mess to decide whether a bootloader has been revoked or not, which, and I very much hope I can be proved wrong here, Microsoft is providing no explicit details about. Especially, it does not say what version numbers are being revoked, and it is also my impression that the hashes revoked by SKU SiPolicy are not in the UEFI CSV... |
Indeed, Microsoft explicitly state here:
So, everything that is meant to be rejected after Windows 10 1507 has not been made public by Microsoft, and, as much as I'd very much like it to be otherwise, my initial comment about Microsoft not publishing information that they should provide still stands (and is made worse by the fact that we can't just rely on getting our hands on a list of hashes). |
I guess the other option we have, since we're going to have to deal with a version whatershed anyway, is to not bother with hashes and just check the version number from the EFI bootloader to display a warning if it's anything below the 22H2 v2's version (which appears to be Note that there is an additional |
Interestingly, if we need to download a It does seem however that Microsoft might have taken steps to try to prevent these kind of downloads as I can't seem to manage to get this to work. For instance, the following to retrieve a PDB will work just fine (symbols for the latest
But trying to do the same for the associated binary, which should resolve to Using the same method I used to generate the Goddammit, this is so annoying! What the hell does one have to do (besides becoming a full blown malware author) to be able to download a simple executable from Microsoft?? |
Even more interestingly, since it appears that we can easily download Windows 8.1's |
Gotta also leave https://support.microsoft.com/en-us/topic/kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d#updatebootable5025885 here. Of course, it would be A LOT better if Microsoft did bother to check the "content" they provide an have an actual working hyperlink for:
In short, Microsoft needs to provide a direct download for the non-vulnerable |
What a load of crap this whole thing is! So I updated a system following the 3. APPLY the revocations steps from Microsoft, doing everything as described (double reboot, wait 5 minutes, confirm in Event Viewer that there's an entry that says that DBX has been updated) and then created a Windows 8.1 bootable media (from So much for:
Unless both Microsoft and Linux are lying, my system should have the latest DBX applied:
And I can tell that Secure Boot is really enabled and enforcing validation, since I do get a big fat Secure Boot validation error when I try to boot the unsigned UEFI Shell... Someone, somewhere, is not telling the truth... |
Maybe the efi files from that iso are not revoked? |
The thing is, if you try to lookup plain SHA-256's in the CSV, from a revoked executable, you will not find it either. That's because the "flat" SHA-256's provided by Microsoft are not the SHA-256 you get by computing the hash for the whole file (because, of course, that would be too straightforward, and who wants to be straightforward and non-obtuse when dealing with matters of security...), but the hash you get by Frankenstein's Monstering only a selection of sections from it (and, yeah, technically, that might make sense as the Secure Boot signature does not apply to all the PE data in the first place, so one could defeat the DBX by altering one of these sections, as they wouldn't invalidate the signature, but would change the hash from the DBX, though I would counter with WHO IN THEIR RIGHT MIND DECIDED THAT HASHING A FILE FOR FRIGGING DIGITAL SIGNATURE VALIDATION SHOULD NOT BE ON THE WHOLE ORIGINAL SOURCE BINARY BUT INSTEAD ON SECTIONS CHERRY PICKED AT RANDOM?!? HOW HARD WOULD IT HAVE BEEN TO DESIGN A NEW PE CONTAINER EXTENSION THAT COULD EMBED THE ORIGINAL BINARY WHOLESALE + DIGITAL SIGNATURE INTO A SIGNED PE FILE INSTEAD OF THIS COMPLETE SECURITY ABOMINATION THAT ULTIMATELY FORCES EVERYONE TO HAVE DEAL WITH THIS MICROSOFT INDUCED BULLSHIT?). So, if all you have is a EFI binary, and you want to find out if it's in the Microsoft published DBX, well, better be ready to code your own SHA-256 hashing application, because good luck finding a standalone SHA-256 computation application that can deal with the intricacies of PE hashing for Secure Boot... Thankfully, after much searching and sieving through bullshit, I found that the obscure PE256 value that Microsoft also does provide in the CSV is actually the SHA-256 "hash" that For instance, if you issue All this to say that, whereas Microsoft were supposed, and have indicated, that all their Windows 8, 8.1 and 10 UEFI bootloaders prior to 1507 should have been entered in the DBX, the And I guess that, now that you know how to validate whether a Windows UEFI bootloader executable is in the DBX, you too can play the game of "What other Oh and incidentally, trying to boot a USB media created from |
I see neither values are listed for 6051480.iso files the list might have glitches, or they forgot to revoke some files |
Yeah, my worry here is that those missed EFI bootloaders, which the DBX does let through (it's not a list issue, it's a DBX issue, as I did validate that these bootloaders are being let through on a fully updated system), might be compatible with newer Windows (whilst ignoring the |
Note: I have just e-mailed the UEFI Forum administrators as well as the Microsoft Secure Boot signing team with my concerns about these missing Windows 8.1 bootloaders from the DBX. Oh, and for the record, these bootloaders were built in 2014.03, and look a bit too early to have benefited from the post 2015.07 revocation features... UPDATE: On advice from Microsoft, I have also created a new vulnerability report (VULN-102832) at https://msrc.microsoft.com/report/vulnerability. |
Doesn't KB5025885 article state that |
Doesn't KB025885 also not provide any instructions on how one should update ISO/USB/DVD media ("update the media by following the instructions here." with no hyperlink)? Again, there are no two ways of going on about bootloaders that should be revoked because they can potentially be used to infect one's system: They must be filtered out with an obvious security violation on a Secure Boot enabled system, so that users are clear about what they are about to do. Now, of course, in a context where you either created your own media (which is the context of the KB) or you are using media that came from Microsoft themselves, it does make little sense to try to filter the bootloaders because that media should be considered safe, and However, in the context of Rufus, I have no way of telling if the source media is safe (and I am not going to add a very costly SHA-1 validation to check for retail ISOs, especially as a lot of folks are going to use MCT ISOs anyway which should be considered safe but cannot be validated for safety). Furthermore, the creation of boot media using Rufus from a Black Lotus infected ISO (or a Black Lotus derivative) is a real scenario that I expect to happen, so, again, I do want users to make their own explicit decision (especially if they are using dodgy-sourced ISOs) when it comes to potentially lowering the security of their system as well as nudge them towards using a more up to date ISO. And, yeah, I am well aware this will annoy a lot of people, but that's how security works, and the minute you attempt to compromise security for convenience (which, IMO, is what Microsoft are doing by not advising people to copy So, I am just going to re-state what I just said above, regardless of what Microsoft states (who, as we have seen, are not impervious to botching security): In an ideal world, all the Microsoft EFI bootloaders prior to 2305 should have been added to the UEFI DBX and should generate a Security Violation in a Secure Boot enabled environment. As such, so that the majority of users remain safe, especially if they are using ill-sourced ISOs, I want Rufus to create media that behaves as close as possible to that ideal situation, and this entails going against Microsoft's "recommendations" and copying the system's |
Seems as though Microsoft Surface devices also look at that file to decide what should trigger a secure boot violation |
@pineapple63, thanks for the report. That's actually part of the reason why I think Microsoft's "advice" about not copying So, clearly, Microsoft, in its actions (rather than in its words) is telling us that any of their pre 2305 EFI bootloaders should generate a Security Violation. And the only way to get that on non-Microsoft controlled hardware, for post 1507 media, is to manually copy the system's |
Update from Microsoft with regards to the missing DBX entries MSRC case:
So, yeah, they acknowledged that their DBX update is currently incomplete, which I'm going to assume means that you might still be able to get infected by Black Lotus, on a fully up to date system, until January 2024... |
Tonight, on the ongoing saga of whatever the heck Microsoft is doing to try to mitigate Black Lotus we attempt to take a closer look at:
The idea is that, since I am planning to detect EFI bootloaders that have been revoked by the DBX in Rufus and warn the user about them (hence why I just added PE256 hash support), I also wouldn't mind being able to do that for bootloaders that have been revoked in the That's because, as one would expect, You can download the converted XML below: Allegedly, all of the Soooo, the question now becomes: What the hell is Microsoft hashing then??? I guess it makes a modicum of sense that Microsoft would not use the EFI hashes, since I have tried to see if So, if anyone wants to pick a post 1507 pre 1607 Windows 10 ISO to play the "What the hell is Microsoft actually hashing in |
1607 ISO is the oldest i still keep 😀 |
Been using a 1511 ISO, and haven’t had any luck so far (And i did verify my Surface Go 3 rejects that ISO when extracted to a USB drive (i copied the files across manually, rather than using Rufus), and in the process of verifying that i screwed up, i wanted to make sure it booted with secure boot turned off, and the device froze when i did that, after force powering it off, and re-enabling secure boot, i was met with a bitlocker recovery screen) |
Goddammit! Why do I always pick the ISOs that Microsoft forgot to add to their deny list? Can confirm that The thing is, since I wasn't sure whether Microsoft's list was inclusive or not, I deliberately picked 1511 as the "safer" bet, since it's right between 1507 and 1607. And I tested multiple 1511 ISOs I had. So, once again, it looks like Microsoft screwed up their Black Lotus filtering, even though, in the case of SkuSiPolicy, they don't have to worry about limiting the bootloaders they pick so as not to run out of space. I sure am starting to grow tired of having to tell Microsoft how to do their job. But at any rate, many thanks to @stdin82 for finding at least one ISO that Microsoft did properly filter out... |
Umm. So where do I find a bootable ISO that doens't have this error? Windows official download of windows server 2019 gives me this warning in Rufus, and I don't want to deal with this in Q1 2024 |
You need to use an ISO that was released after May 2023. If Microsoft released a Windows Server 2019 ISO after May 2023, just like they re-released Windows 10 and Windows 11 22H2 ISOs, then you should use that. If not, then you need to ask Microsoft if they are planning to release one or temporarily disable Secure Boot during install on a system where the UEFI lock has been enabled, and reenable it after the system has been updated. From what I could see from testing with the pre 2023.05 Windows 11 ISO, Microsoft seems to ensures that the very first update that gets automatically installed on a newly installed Windows system is updated UEFI bootloaders, so you should usually be able to re-enabled Secure Boot very quickly and temporarily disabling Secure Boot is not the end of the world if you are working with images that you downloaded from a trusted source. |
Hmmm, I'm surprised the Oct 2023 updated ISOs would produce that message.
Temporarily disable Secure Boot before trying to install Windows, and let Windows Update install the updated Windows bootloader (this will come as a priority update after you installed the OS). Once that is done, you can re-enable Secure Boot. Your screen says Secure Boot is in Setup mode though, so I'm not sure about your current Secure Boot status... |
The thing is secure boot is completely turned off. In the screenshot it says 'secure boot : setup'. I've completely ran out of ideas. |
Maybe, if you haven't tried that, you want to enable Secure Boot then (for third-party CA, not Microsoft CA - you should have 3 options in the menu). UEFI:NTFS is Secure Boot compatible, and I'm curious about whether you get a different message then. |
Secure Boot is completely turned off. It's a Surface Laptop, I don't have the options to turn off Microsoft CA. Only the following options: |
Yes, that's what I mean, try with Secure Boot set to Microsoft & 3rd party CA. |
Hmmm, I wonder why your Secure Boot status still says "Setup" though... I know some UEFI firmwares are weird, but this means that the EFI Secure Boot variable |
I just tried rufus 4.1p instead of the latest one and this is the new error |
From Microsoft's own documentation about Secure Boot:
So, if you really did enable Secure Boot, then it looks like Microsoft does not follow its advice to OEMs on their own hardware, because the only way UEFI:NTFS will report
Don't. This is expected, and, as explained above, I changed the nondescriptive By the looks of it, you may want to check if your Secure Boot environment has been properly initialised on your system and if it has, the ask Microsoft why the heck, when enabling Secure Boot on a surface device, it appears that the |
Maybe I was wrong when explaining, when SecureBoot is turned off, I get SETUP when I boot from the USB. But when it's turned on (and 3rd party CA enabled) I get ENABLED. |
Ah that makes more sense. But then please don't reuse an old picture when attaching an image to state that the behaviour hasn't changed. Either don't attach a picture at all, or, if you do, make sure you do take a new picture. At any rate, without being able to test this issue, I have no more advice to provide. And to be honest, whereas the message you do get is a message that was added as a result of this topic, your issue, appears to have to do with specific Surface behaviour and should be considered off-topic. |
Are you sure that the hashes in SkuSiPolicy represent PE256 hashes of the revoked binaries? I tried Get-AppLockerFileInformation to get the hashes for some Win 8.1 bootmgr.efi's but couldn't get a match |
The 8.1 bootloader hashes are revoked through the standard UEFI Revocation DBX, on account that revocation through SkuSiPolicy was not yet implemented in 8.1. As pointed out above, and from the official UEFI documentation:
|
Ah my bad, thank you. I still struggle to understand how they managed to get a list of over 2300 binaries for only these few versions (even if the list contains x86\_64 and ARM) |
The skusipolicy indeed contains PE256 hashes. I checked for example some rs1 bootmgfw hashes and they were in there. skusipolicy was first implemented in th1 (and originally for applying Surface Hub-specific restrictions), so of course no win8/winblue binaries would be in there! |
MS updated their page again and pushed the third deployment phase back to 2024-04-09, and mandatory enforcement to 2024-10-08 (six months later), thus marking the second time they pushed back the next round of revocation. |
Joy! |
I decided to reverse the dll that does the db/dbx updates, since the new UEFI cert recently appeared in latest Insider builds ( It also can handle a (the debug strings in question are: This is gated behind a (registry?) flag. It's currently unknown whether all systems will end up getting the old cert revoked, or whether it'll just be new systems (with preinstalled Germanium), especially considering MS talk (slides, video) which mentions problems like bad OEM implementations not implementing db update correctly (where updating db either does not work at all, or can even brick the system). |
All supported versions got it |
This is referring to the db update, not a future dbx update where code is present but the actual update file is not (yet). |
Windows 11 build 26100 now contains The interesting thing is that this build is still signed by the old cert (for the most part - a copy of bootmgfw signed by the new cert is present, but it does load and use dbx so the following still applies) - I missed that the cert revocation checks in the windows boot environment only checks for hash of cert, and not the cert itself, so the boot environment would ignore the entire cert in dbx and still allow binaries signed by PCA 2011! Which seems incomplete to me, maybe additional revocation lists (skusipolicy, boot.stl etc) will get released on Tuesday... |
Is there a summary of the current situation (this is a huge amount of text to follow up) ? It seems that 4.4 does detect the revoked bootloader already, but it does not mention a possible replacement of the bootloader. Did the replacement fail or is it just not "user-friendly" yet? Thank you. btw: wouldn't it be a good idea to change the title if microsoft postponed dthe enforcement from Q1 2004 to 2024-10-08? (which is mentioned in one of the many comments) |
The summary is that, ultimately, on any machine where you have ran (a currently supported version of) Windows, any bootable media created from a (Secure Boot compatible) Windows ISO that was produced before 2023.05 will produce a Security Violation error in some form or another, because all Windows UEFI bootloaders produced before 2023.05 are vulnerable to BlackLotus and have been revoked. Or, to put it even more simply: Don't use anything Windows that has not been updated after 2023.05, in a Secure Boot enabled environment or else you will see boot errors.
There is no replacement of the bootloader. We briefly considered it, but Microsoft removed access to UEFI bootloader downloads from their debug servers (even for new unaffected bootloaders) precisely because BlackLotus exploited the ability to download UEFI bootloaders, and, because this is proprietary copyrighted content, Rufus cannot simply pick bootloaders from newer ISOs and make them available for replacement without running afoul of copyright law. Instead, it must download them directly from Microsoft... which it cannot do. Which means the best Rufus can do is warn about the revocation, which it does, and ask you to source a non vulnerable ISO, which is really what you should do (or temporarily disable Secure Boot if you are 100% certain that your content came directly from Microsoft and has not been tampered with, and then re-enable it once your Windows installation is done, as the very first thing Windows Update does on a fresh install these days is replace vulnerable bootloaders).
Well, the thing is, this is a roll-out, with different parts (UEFI revocation DB, voluntary UEFI Lock, mandatory UEFI lock) being applied at different times, so there's no hard target for the full enforcement date, which, IMO, means it's better to be conservative. As far as I can tell, the reason you come here is because you have been affected despite the fact that the full revocation has not been enforced yet. So, from where I stand, Q1 2024 is fine, because we very much expect to see more and more people being affected by the revocation in Q2 and over the subsequent quarters. |
Thank you for the summary. Well, I was affected by seing the warning, not by having boot issues, and because I was curious to find out whats behind it. I understand the issue with the bootloader not being available online anymore and the copyright issue with shipping them with rufus, but wouldn't it be a valid workaround if the user would provide either an updated bootloader or an ISO current enough to have the new bootloader? Or, if that is not worth it, a FAQ entry telling how to replace the bootloader on a rufus-created thumbdrive using a current ISO as the source. Windows Server 2019 is in extended support until January 2027, so it is a "currently supported version" of Windows, but - as I was warned by rufus - it seems to have the blacklisted bootloader. Afaik there is no newer ISO for Server 2019 like for the Client Oses, is there? So I assume that this affects Hyper-V Server 2019 as well which will be the last version of Hyper-V Server ever (well, a Microsoft-forever, maybe its the last just like Win10 was :D) Thanks. |
It seems like Microsoft was publishing updated ISO's for Server 2019 up until June 2021 and then stopped for some reason. |
Checklist
<FULL LOG>
below.Rufus version: x.y.z
- I have NOT removed any part of it.Additionally (if applicable):
(✓)
button to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.Issue description
Due to changes to the Windows Boot Manager from CVE-2023-24932. Previously created boot media will no longer be able to boot once enforcement begins Q1 of 2024. If possible, detect this issue and provide a warning.
https://support.microsoft.com/en-us/topic/kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d#avoidissues5025885
Log
N/A
The text was updated successfully, but these errors were encountered: