Feature Request: Report and validate the Microsoft SVN

[pbatard]

This project and its scripts are great.

But one thing that is missing at the moment, that's equally important as validating the DBX hashes, is SVN validation, as Microsoft does push regular SVN updates into the DBX, and SVN acts as a Secure Boot gatekeeper for Windows Bootloaders, in that, the first thing the Windows UEFI bootloaders do, in a Secure Boot environment, is check the SVN number from the system/DBX against their own SVN, and if they find that their SVN is lower than the system, they produce the following error:

In other words, if the latest SVN is 7.0 (as it currently is) but the current platform's DBX SVN is 5.0 (which was the case earlier this year), then it means that a platform that reports check marks everywhere with the validation script is actually vulnerable, since it will allow Windows bootloaders, including CA2023 signed ones (so being CA2023 compliant will not save you here) in which vulnerabilities have been found.

Which is why we would encourage a a script that cares about revocation to also report the SVN status.

Basically, the validation script should report 3 elements:

1. The most up to date SVN value from Microsoft, which currently should be 7.0, and which was updated at least twice this year. This should be reported independently of what is read from the system (i.e. most likely hardcoded, unless you want to extract it dynamically from https://github.com/microsoft/secureboot_objects/blob/main/PostSignedObjects/Optional/DBX/amd64/DBXUpdateSVN.bin where it resides... provided Microsoft actually bothers updating that file — see below).
2. The current SVN value of the platform's DBX, which, should also be 7.0 on fully up to date systems.
3. The current SVN value of the platform's Windows UEFI bootloader, to make sure that if someone finds that the DBX reports an SVN of 7.0 but their Windows bootloader are still on 5.0 or less, they get a hint that they should first update their bootloader before going around updating the DBX.

Now, getting the SVN value from the DBX is something that can easily be accomplished with this PowerShell snippet (taken from this relevant elevendorum thread):

$DBXSVN=([Regex]::Matches((((Get-SecureBootUEFI dbx).Bytes |% {'{0:x2}' -f $_}) -join ''),'01612b139dd5598843ab1c185c3cb2eb92...........')).Value | sort | select -last 1; if ($DBXSVN.Count) { 'SVN {0}.{1}' -f [int]::Parse($DBXSVN.Substring(36,4),[System.Globalization.NumberStyles]::HexNumber), [int]::Parse($DBXSVN.Substring(40,4),[System.Globalization.NumberStyles]::HexNumber) } else { 'No SVN.' }

Getting the SVN from the bootloader is a bit more involved, but is probably similar to what's being accomplished to check the Secure Boot certifcate.
If needed, you can reference the C code that I'm using in Rufus to perform SVN validation check in https://github.com/pbatard/rufus/blob/a8c745d2a95c590e7607836b3ee5365186840dcf/src/hash.c#L2274-L2324.

As to getting the most up to date value from Microsoft, this might require even more involvement, because, theoretically, Microsoft should push a public DBX update at https://github.com/microsoft/secureboot_objects whenever they push an SVN update through Windows Update, but their current track record on doing that hasn't been that great, which forced me to open an issue with them in microsoft/secureboot_objects#255, so I hope their future SVN updates will be more coordinated between their Windows Updates team and their Secure Boot teams...

All in all, once SVN validation is added to the script, I believe it will be the ultimate means for Windows users to validate that their platform is really up to date in terms of Secure Boot.

[cjee21]

Checking SVN and SBAT is on my todo list but I've yet to figure out how. Thanks for the method to check SVN. I'll try adding it to the script when I have time. Do you have any idea on how to check SBAT? SBAT is like the SVN equivalent but for Linux and is required to revoke all vulnerable Linux loaders even if the user is not using Linux. Windows actually has built-in mechanism to update the SBAT although I'm not sure if it is still done automatically now since they caused some Linux installs to be unbootable in the past.

[cjee21]

The latest SVN can be obtained from the json metadata provided by Microsoft.

    "svns": [
		{
            "value": "01612B139DD5598843AB1C185C3CB2EB92000007000000000000000000000000",
            "version": "7.0",
            "filename": "bootmgfw.efi",
            "guid": "{9d132b61-59d5-4388-1cab-185c3cb2eb92} == EFI_BOOTMGR_DBXSVN_GUID",
            "description": "Windows Bootmgr SVN CVE-2023-24932",
            "dateOfLastChange": "2025-06-06"
        },
		{
            "value": "019D2EF8E827E15841A4884C18ABE2F284000003000000000000000000000000",
            "version": "3.0",
            "filename": "cdboot.efi",
            "guid": "{e8f82e9d-e127-4158-88a4-4c18abe2f284} == EFI_CDBOOT_DBXSVN_GUID",
            "description": "Windows cdboot SVN CVE-2023-24932",
            "dateOfLastChange": "2024-04-01"
        },
		{
            "value": "01C2CA99C9FE7F6F4981279E2A8A535976000003000000000000000000000000",
            "version": "3.0",
            "filename": "wdsmgfw.efi",
            "guid": "{c999cac2-7ffe-496f-2781-9e2a8a535976} == EFI_WDSMGR_DBXSVN_GUID",
            "description": "Windows wdsmgfw SVN CVE-2023-24932",
            "dateOfLastChange": "2024-04-01"
        }
	]

Do you know what are the other two SVNs for?

[pbatard]

First of all, thanks for looking into this.

SBAT is stored in the firmware as a variable with variable name SbatLevel and variable GUID 605dab50-e046-4300-abb6-3dd810dd8b23 (which is the EFI VendorGUID used by the Linux Shim). So if you can read Secure Boot variables, you should be able to read the SBAT variables as well.

Getting the latest SBAT programmatically from the authority (Red Hat Shim), in the same manner as you would get SVN from Microsoft, is a bit more involved, because right now, you have to wade through the multiple entries of https://github.com/rhboot/shim/blob/main/SbatLevel_Variable.txt to figure out what to use. I asked the Shim folks to provide an authoritative, parser friendly file, in rhboot/shim#685 but haven't seen any progress on that which means that, for Rufus (since I also perform SBAT validation there) I'm using my own self-maintained sbat_level.txt at https://rufus.ie/sbat_level.txt with the one up to date data that matters (and I also have a cron script running daily so that if the Shim's SbatLevel_Variable.txt gets updated, I get notified and can update my sbat_level.txt within 24 hours).

As to the additional SVNs, these are for optical and PXE boot, which I'm not sure you want to care about (since I would be surprised if people boot live Windows from optical media... they might do it from PXE, but I'm pretty sure you're going to waste your time trying to look for PXE bootloaders and confuse regular users about these, in the super rare case someone might be booting a live Windows — not an installer — from PXE).

This is something that we talked about in the (infamous and ongoing) Rufus thread were we started looking at the PCA2011 revocation: wdsmgfw.efi

[pbatard]

Oh, and I should mention that, since I couldn't rely on Microsoft to update the SVN in a timely manner in https://github.com/microsoft/secureboot_objects (and I fear that the next time we see an SVN update, secureboot_objects will still be trailing behind Windows Updates for weeks... or months), you'll see that, for convenience, I also have the latest SVN in https://rufus.ie/sbat_level.txt (under BOOTMGRSECURITYVERSIONNUMBER).

Unfortunately, since we can't rely on Microsoft to notify folks on SVN updates, that SVN gets updated manually if I find that there has been an SVN update one way or another (one of which being to check the SVN version of the DBX SVN update from Windows itself, which isn't exactly ideal). Which makes me think I probably want to set up a scheduled script that does just that too...

[cjee21]

So if you can read Secure Boot variables, you should be able to read the SBAT variables as well.

Provided that it is not Boot Services only type of variable which can only be read when in a UEFI shell.

[pbatard]

Provided that it is not Boot Services only type of variable which can only be read when in a UEFI shell.

Ah yes, sadly, you might be correct: https://github.com/pbatard/Mosby/blob/main/src/data.c#L7630

We write SbatLevel as Boot Services only, and not Boot Services + Run Time like the Secure Boot variables...

[pbatard]

It does look like there's a second SbatLevelRT variable specific for runtime, that could be read:
https://github.com/lcp/mokutil/blob/master/src/mokutil.c#L2354-L2356

[cjee21]

It does look like there's a second SbatLevelRT variable specific for runtime, that could be read: https://github.com/lcp/mokutil/blob/master/src/mokutil.c#L2354-L2356

But is that only generated by Linux or is it also available on Windows? I'll check later if Windows has written any SBAT variable on my system.

[pbatard]

Yeah, I'm not sure if a Windows SBAT update, like the one Microsoft pushed last summer, would update the RT variable too.

And I'm also not super conclusive, from the Shim code itself, that that variable will always have RT:
https://github.com/rhboot/shim/blob/afc49558b34548644c1cd0ad1b6526a9470182ed/mok.c#L367-L386

On the other hand, I'm not too sure whether BT-only variables can be written to from the OS, and the OS must obviously be able to update the SBAT variable, so maybe that's why we have the RT variable in the first place...

In other words, my current guess is that maybe the SBAT update process from the OS is to write to SbatLevelRT, and then, when shim boots, it first looks at the SbatLevelRT value, and updates the SbatLevel if it finds it needs updating (which would be a very convoluted process when you can just make SbatLevel RT in the first place, so I'm not sure that guess is correct). And if that is the case, then Windows would also update SbatLevelRT.

[pbatard]

Okay, with some input from ChatGPT (which, as usual, may be wholly inaccurate, so take that with a grain of salt):

SBatLevelRT is not written by Linux

SBatLevelRT is a runtime projection of SBatLevel created by shim itself after booting and after ExitBootServices().
Linux cannot meaningfully write or modify it, because:

The firmware (or shim) creates SBatLevelRT at boot based on SBatLevel

It is volatile and exists only while the OS is running

It is meant to be read-only from the OS perspective

➜ When the OS updates the SBAT level, SBatLevelRT does not immediately change.

It also seems (still according to data digested by ChatGPT) that the SBAT update process is supposed to be carried out by the Shim in that, whenever a new Shim finds that its embedded SBatLevel is more recent than the one in the UEFI variable, it updates the UEFI variable before proceeding. So there's no updating of SBatLevel from the OS itself. All the OS does is install a newer Shim in the ESP, and the Shim takes care of the rest.

This would mean however that Microsoft had to add extra code in its Windows UEFI bootloader, before it exits BootServices, just to perform that SBAT update they did in summer, since it could not be performed from the OS...

But more importantly, the above about Shim creating SBatLevelRT, if correct, also means that if you boot Windows, then you have no way of getting the current SBAT value...

[cjee21]

if you boot Windows, then you have no way of getting the current SBAT value

So no easy way for a typical user to check if the vulnerable Linux loaders have been revoked.

[pbatard]

That's my understanding.

There is also a chance that I got it wrong in Mosby (since I tried to make sense of what the whole conditional mess of attributes from https://github.com/rhboot/shim/blob/afc49558b34548644c1cd0ad1b6526a9470182ed/mok.c#L367-L386 boiled down to), and that the SBatLevel variable is ultimately RT (though it would be weird that Shim would find the need to create an SBatLevelRT variable then).

I guess testing with a real Linux system is probably warranted, just to make sure. I'll see if I can get around to do that.

[cjee21]

the additional SVNs, these are for optical and PXE boot, which I'm not sure you want to care about

Even if no one boots from them, the vulnerable ones should still be revoked right? I added checks for those too as Windows does update those SVNs.

[cjee21]

By the way, that one-liner from elevenforum seems to be wrong. It is reading the wrong bytes.