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. |
|
A few more random notes, for those who might be interested in this whole thing:
At this stage, considering that trying to secure systems of unaware users is something that applications should strive for (rather than let unaware users potentially get infected through known easily patchable security holes), I am planning to have Rufus automatically copy the system's My reasoning is that, in an ideal world, all the bootloaders for which And this is where we might for once be helped by |
|
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... |
|
It seems microsoft have already started removing the |
|
You're right, latest CU has removed SkuSiPolicy.p7b |
|
It seems that, after removing the file altogether, the latest patch tuesday update applied a new Oh and in other news, it seems that |
|
Out of curiosity i compared the old (well, the one from the most recent
public ISO) and new ones using a basic text editor, and noticed something
interesting
The old one just shows as a bunch of meaningless characters, but the new
one has a section at the beginning which seems to be referencing file names
…On Sun, 18 Aug 2024 at 14:29, Pete Batard ***@***.***> wrote:
It seems that, after removing the file altogether, the latest patch
tuesday update applied a new SKUSiPolicy.P7b (In
C:\Windows\System32\SecureBootUpdates), though this new one doesn't seem
to have revocations yet:
Found 0 additional revoked UEFI bootloaders from this system's SKUSiPolicy.p7b
Oh and in other news, it seems that Microsoft now has an optional(?) KB
update (KB5041160
<https://support.microsoft.com/en-us/topic/august-13-2024-security-update-kb5041160-3e8026f2-bb4c-4c1c-9855-d41e1b5b1bd9>)
where they update the SBAT to prevent any pre 2024.08 Linux Shim from
booting due to a vulnerability that I have not been able to clearly
identify (I currently suppose it's CVE-2023-40547
<https://threatprotect.qualys.com/2024/02/12/critical-vulnerability-in-shim-impacts-major-linux-distributors-cve-2023-40547/>,
but it looks like Ubuntu 24.04 is affected
<https://askubuntu.com/questions/1523683/bootloading-ubuntu-24-04-iso-error-sbat-data-failed-security-policy-violation-w>,
whereas I would expect them to have had a chance to patch their Shim).
—
Reply to this email directly, view it on GitHub
<#2244 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A2L7IPF2GGRKN24OESUSNPTZSCOTNAVCNFSM6AAAAAAX7TSZJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJVGI3DGMRTGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
With the SBAT update, it appears to affect Windows 10 as well |
…N based revocation * See 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 as well as pbatard/rufus#2244 (comment). * Note that dbx_update_2024_all.bin contains an ESL with an SVN update, but dbx_update_2024_svn.bin bumps MinimumAllowedVersion from 0x020000 to 0x030000 so both need to be applied. * Also, since dbx_update_2024_all.bin tags 'Microsoft Windows Production PCA 2011' as explicitly revoked, and we were planning to remove it anyway, we obviously no longer add it in our DB data. * Also update the signed ESL check in pki.c to account for databases with multiple ESLs.
|
Sooooo... from my testing, it appears that the installation of the What this means is that, if you happen to manually revoke the And yes, I tried multiple reboots, as advertised, but only got the bootloaders when Windows was running in a Secure Boot enabled environment. So, congrats Microsoft! You have found a new innovative way to add an completely unnecessary hoop to a procedure that already requires jumping through a whole slew of them... 2026, where the 2011 certificate ceases to be valid altogether (and where Microsoft will be left with no choice but to make things work with the 2023 cert by default) really cannot come soon enough. Besides, if we're lucky, maybe Microsoft will have figured a KB5025885 that isn't full of holes by then... |
Easier and in short is that (according to pbatards own FAQ) consider Secure Boot being overrated (especially how Microsoft's attempt to fix the so called Blacklotus only closes the avenue of using non-stock Windows installations and even also Linux) and that if the user wants to install non stock OS (including using Rufus features and dual booting Linux) the user would have to turn Secure Boot off in order to make it work. If Secure Boot is really necessary then consider turning it on only if additional booting operations that are manually supervised (like installing OS) aren't done. Especially how (apparently) secure boot can be toggled in an "in-place" OS installations without errors. Blacklotus also requires physical access in order to exploit it though it is said that remote access (something that normally is not enabled) is possible. Good thing that apart from Valorant, there's no mandatory Secure Boot requirement for running apps, including critical ones. |
Then you misread the FAQ. I'm not in any way saying that Secure Boot is overrated. The idea of being able to whitelist and/or blacklist bootloaders, and make sure that there is some accountability as to what bootloaders can get through by default is one that I am 100% behind. And that is essentially what Secure Boot is (or, as it should really be called, Bootloader Signature Enforcement, since I consider "Secure Boot" to be a promise that cannot really be delivered, as well as false advertisement, but in that case I am talking about the name and not the mechanism, because, as with any part of security matters, the best you can ever hope to do is mitigate rather that promise/imply an absolute). What I am saying, however, is that Microsoft's unchallenged stewardship of the Secure Boot signing process has been disastrous, since Microsoft has been abusing and continues to abuse the power that was granted to them by the UEFI Forum (and I'm not talking only about their no GPLv3 Secure Boot signing stance - their T&C on who can download and redistribute UEFI DBX are also clear unwarranted abuse of power). We're not even really talking about BlackLotus remediation here, since default Secure Boot, on its own, should have been enough to filter out BlackLotus vulnerable bootloaders... had Microsoft not decided that they should have free reign with what they sign and apparently decided to release a new signed Windows UEFI bootloader every other week which, very expectedly, came to bite them right in the ass the entirely foreseeable day where it was discovered that all these bootloaders that were released prior to a certain date were vulnerable and needed to be revoked. Or maybe this is an illustration of abuse of power because, when you are a diligent steward, and you know that there (might) exist a ceiling to the number of bootloaders that can be revoked through the standard revocation mechanism of Secure Boot, you either limit the number of bootloaders you release, or you work with the UEFI Forum to expand on the revocation mechanism (and avoid everybody and their grandma to come up with their own version of SBAT, even if I have to concede that Microsoft's last entry here, that (ab)uses the DBX, has to be the one I prefer... though of course the only reason Microsoft are able to do that is because they are the only ones assured to have a KEK certificate that lets them update the DBX). So, to reiterate my stance: I am 100% for Secure Boot (even if it's a misnomer). I'd like nothing more than everybody to use Secure Boot. But I am 100% against the signing process (and DBX update process) being in the hands of one entity who has demonstrated time and again, that they should not be left in control of it... Also the requirement for physical access does not diminish the vulnerability. Else, you might as well say that having a lock screen on your phone is pointless, since it's "merely" a protection against physical access, and exploitation that requires physical access is not that dramatic (which I am interpreting as one of your argument). |
Well to quote several lines of FAQ that i read: "So, I must first stress out that, instead of being paranoid about it, you should come to terms with the fact that YOU are actually being manipulated with the terminology that Microsoft (and others) decided to use when they introduced Secure Boot because it was deliberately chosen to convey something that it cannot really deliver (See for instance the fiasco of Microsoft's Golden Key). Instead, Secure Boot should more accurately have been called Bootloader Signature Enforcement because that is really what (and only what) it does" That's what i interpret as "overrated". No further discussion wished given that: |
|
Yes, I did explain above that, similarly to what I state in the FAQ, for one thing, the term "Secure Boot" is a manipulative misnomer and, as you appear to agree, one should not be afraid to temporarily disable Secure Boot if they have to (while following basic safety rules when doing so). That should not however be in any way construed as me stating that "Secure Boot is overrated", and I'm afraid that if you or someone else implies that I am saying the opposite of what I am actually saying, I am left with no choice but to strongly dispute that statement. Otherwise, if left undisputed, people may come to see it as tacit agreement. In short, I have no problem if you or somebody else want to summarize the FAQ content on the subject as a statement that the terminology is manipulative or that the entity in control of the signing process has not proven worthy of such power. I do have a problem however if the FAQ content is being reduced to a blanket statement that is very misleading at best, especially if, as opposed to the FAQ, it doesn't make the distinction between the terminology and the technology. |
|
Just going to make a note that the new Sadly, Microsoft has still not reinstated |
If you or somebody else (especially Linux system builder) could manage to apply the new signature/CA, that will be a good step toward keeping to use Rufus or non Ubuntu Linux in a secure boot environment. Only time will tell though as the clean ISO of 24H2 got released in the end of 2024/beginning of 2025. |
This ISO has just been released to the general public today. And its bootloader is still signed using
Well, of interest to us is that this ISO contains the The BIG issue however, which is what I alluded to above, is that while replacing the And even if Rufus were to do something like modify the That's not to say I'm not going to explore the possibility of doing something like this in Rufus. But it's unlikely to happen soon, and there are many factors that could make it a nonstarter... |
there's always wimlib, which is faster (no need to mount to extract from or modify files in a wim) |
|
Last time I checked, wimlib was pretty heavy for an executable that is very size conscious... For this reason, when a native Windows API exists, I always try to use the native API in Rufus. At any rate, speed/perf optimization will have to come way after I check if it even makes sense to go all the way in on the 2011 cert revocation, as this is going to be a transient problem that will naturally solve itself anyway sometime in 2026 (or, hopefully, earlier), when Microsoft is no longer able to sign anything with their expired cert... |
* This allows Rufus to perform SVN revocation checks on Windows UEFI bootloader per: pbatard/rufus#2244 (comment)
* See #2244 (comment) * Note that we don't use the GUID but the resource name for bootmgr.efi, as trying to figure out where the heck the relevant GUID is located in the PE code is not worth the effort. * Also add internal fallback for sbat_level.txt if the user can't access our remote version. * Also improve PE section lookup.
|
Just going to point out that, thanks to @Wack0's excellent documentation of the new SVN feature in #2244 (comment), the next version of Rufus will perform Windows EFI bootmgr SVN validation and alert users in case Microsoft has revoked their bootloaders through an SVN DBX update. Note that, since this is SBAT in disguise (and I actually wish SBAT followed suit with using GUIDs in DBX for SBAT, which I have to agree is the much better way to do blanket revocations), and since I already added SBAT revocation validation through an Once again, major props to @Wack0 for providing the in-depth data I needed to add this feature. |
|
Sooooo, as I alluded to above, I'm currently experimenting with trying to create Windows installation media in Rufus that can work on systems where The good news is I can get both the initial (USB) bootloader and the target disk (HDD/SDD) bootloaders to use The bad news is that, somehow the 2023-signed bootloader that the first stage installer installs onto the target disk is one that has an SVN of
I guess the silver lining is that we finally know what the Microsoft SVN violation screen actually looks like. And indeed, looking at the So, first of all, the obligatory "WTF are you doing Microsoft? I know you wanna freeze stuff early for RTM, but when there's a bootloader vulnerability, that you have patched at least 2 months before GA, shouldn't you have used that timeframe to update the frigging bootloaders?" And second, I find that I currently have no idea where the bootloaders Windows setup installs to the target partition come from when So it looks to me like, when the installer detects that the media was booted through a PS: Oh and in typical Microsoft fashion, the https://aka.ms/secure-boot-version-violation URL, that is referenced in the error screen, does not currently work... |
I knew for months what it should look like, as I reversed this code. I assume that the URL will eventually work, probably closer to the enforcement phase, whenever that will be. nice to see a screenshot though.
It should come from windows\boot of whatever install.wim index got installed (different indexes can have different versions). Setup DLLs call bootsvc!BfsServiceBootFilesEx passing %installdrive%:\windows\boot as first arg, bcdboot.exe also has its own copy of the same code. |
|
Windows Setup detects 26100.1 Windows UEFI CA 2023 and applies bootmgfw_EX.efi. I remmber the error message and find at hard disk additonal files And at the USB stick there is Well, is this a temporarily error only? Editing all install.wim[N]winre.wim does work, adding a current bootmgfw_EX.efi. However imagine a SVN 4.0 update in the future. What to do in future? Some random ideas: There is a UEFI CA 2023 copy file list as for Windows PE for the Windows ADK. Thanks for the bootmgrsecurityversionnumber resource hint. A boot*.efi security version number SVN view at Rufus would be nice to have. |
All updates would need to be applied to the install.wim, including WinRE "Windows Safe OS Dynamic Update", using dism/etc. |
|
@wogwaeb, thanks for the info.
Yup, that's the one. Meaning that direct patching the install media in Rufus for 2011 revocation is a non-starter because, even if patching a single indexed image was acceptable in terms of speed, doing it sequentially for 11 indexes is not going to fly (since, AFAIK, the Windows APIs do not offer the option to update all indexes at once). Besides, since MS forgot to update the
Which is pretty much what we have today, because it all boils down to revocation (the source of the revocation, be it DBX, SBAT, SVN being completely irrelevant) and you simply cannot install Windows from scratch, by simply extracting the official Windows 11 24H2 ISO content to a drive (as one would expect to be able to do), on a system that has been properly updated for all known (and fixed) Secure Boot vulnerabilities that have been officially revoked, and that has Secure Boot enabled. And indeed, if an existing installation media contains vulnerable bootloaders, it should fail through whatever revocation is most appropriate (and users should complain to the OS manufacturer to release an installation source that uses updated bootloaders). So, yeah, when vulnerabilities are addressed and bootloaders get revoked, then installation media created from source data that was released prior to a fix should fail. What's not acceptable however is having an OS manufacturer, that has had updated bootloaders, and that knows that a fully up to date system will prevent vulnerable old bootloaders to boot though revocation, not releasing an installation media that uses these fixed bootloaders (even if they have to release 2 versions of the OS, with one for people who have applied the revocations, and one for those who haven't). Sadly, Microsoft are far from being alone here, with, for instance, the current CentOS Stream 9 producing a Security Violation on account of up to date SBAT revocation, because they still haven't updated their 2023 image even after being aware of the bootloaders they use being vulnerable and are being revoked.
Which is going to be a pain, because there's a bunch of corollary files that Microsoft adds to the ESP (localization and stuff), and that might require updating too in case the updated bootloaders need 'em. And I'm not sure we don't also need to update the target system's
I'll consider it, but it may only be produced with a non-default verbose option, as, to be fair with that feature, we'll also want to report the SBAT levels we detect from shim and grub bootloaders, and, as long as we do report revocation, this kind of information will be of limited use to the vast majority of users... |
… 24H2 _EX versions * This aims at creating installation media that is compatible with systems where 'Microsoft Windows Production PCA 2011' has been revoked. * Doesn't work, since the bootloaders being applied by the first stage installer come from \sources\install.wim[#]\windows\system32\Recovery\Winre.wim[#]\Windows\Boot\ (instead of \sources\boot.wim[#]\Windows\Boot\ as one would naturally expect) and Microsoft botched the ones they included there by using completely vulnerable (and therefore revoked) ones. See #2244 (comment). * Still, I sure haven't gone through this excruciating ACL bullshit for nothing, so you get an experimental option, behind the expert mode curtain.
|
I'll just add that Microsoft were just so close to do things right if they hadn't botched the bootloader files they included in From first stage So, per |
|
I think the MS bug here is using the boot files from winre, rather than the ones from the install.wim image. I wonder if this is a side-effect of setting up the winre boot entry? Anyway, the expected method of updating winre is this: https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/add-update-to-winre?view=windows-11 Unfortunately at least some of the safeos dynamic updates appear to not contain bootmgfw_ex, great job MS. I wonder if just running bcdboot after setup would use the correct files? |
|
Just a quick note to mention that Rufus 4.6 BETA (as well as the release) will display SBAT/SVN info when USB Debug (Alt-.) is enabled. You will therefore see something like ( or something like ( Obviously, since this can produce a lot of extraneous output if there are a few bootloaders being checked, I don't want to have this info displayed outside of additional verbose logging. But it's there if you fancy it. |
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: