Boothole fix
Mayo, Bill
I tried doing the Boothole fix (https://support.microsoft.com/en-us/topic/microsoft-guidance-for-applying-secure-boot-dbx-update-e3b9e4cb-a330-b3ba-a602-15083965d9ca) back when it was first released and had no success—meaning that running the GetString command still returns “true” and the vulnerability shows on a Nessus scan. I finally backburnered the issue and am now trying to get back to it.
I have faithfully followed the instructions in the aforementioned article, many times with a single exception: For step 2b I use “SplitDbxContent.ps1” because the “SplitDbxAuthInfo.ps1” script it indicates does not exist. It is strange to me that this error in the instructions persists after all these months and does make me wonder if I have a different issue. However, there is at least one place I find that somebody indicates the script name is wrong (comment by DMiner at https://answers.microsoft.com/en-us/windows/forum/all/microsoft-guidance-for-applying-secure-boot-dbx/d0b9c235-6ed0-4be8-a497-b33eb750d814?auth=1&page=1).
This is on Windows 2019 boxes and I am using the 64 bit file that is linked on the uefi.org page. The “SplitDbxContent” line does result in the 2 expected files, and I am running the commands from the directory where the files sit. Nothing about the process indicates any issue, except that after a reboot the issue is not mitigated.
Has anyone run into this and/or can provide some insight into what I may be doing wrong here?
Bill Mayo
Michael B. Smith
Can you run a start-trace in the PS session, going through the entire process and post it?
Offlist, if you prefer.
--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
ntsysadmin+...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ntsysadmin/5a941b19a9314a15ae73002b504b90e5%40pittcountync.gov.
Mayo, Bill
Start-Trace or Start-Transcript? The former wants a sessionname parameter and I am not sure what would go there.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/791c12bc89364b9f981f1e16f56a6a6a%40smithcons.com.
Michael B. Smith
Sorry. Start-transcript.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/7cf1a5af0dc745a999fb0feda5b9b914%40pittcountync.gov.
STOSSE Florian (SAFRAN ELECTRONICS & DEFENSE)
Hi,
The GetString always returning True is the expected behavior, even after having applied the update.
The Secure Boot process relies on several cryptographical parts (the Platform Key, one or more Key Exchange Keys, the allow database and the deny database). By default, when you buy a new machine, say from Dell or any manufacturer, the Platform Key is provided by the manufacturer. If you bought it with an active Windows license, you also get at least 2 Key Exchange Keys :
- The manufacturer KEK
- The Microsoft KEK used to sign legitimate Windows bootloaders
These KEK are used to sign the DB (allow) and DBX (deny) databases. By default, the DB contains the 'Microsoft Corporation UEFI CA 2011' entry, that tells the Secure Boot process that any bootloader signed by this Certificate Authority is allowed to boot. This authority is used by Microsoft to sign third party bootloaders, such as the shims used to launch the Grub bootloader (cf. https://wiki.ubuntu.com/UEFI/SecureBoot/ShimUpdateProcess)
In the Secure Boot process, the DBX takes priority over the DB, meaning that if a CA or a SHA256 (you can use a hash to specifically allow/disallow a bootloader or a driver) is listed in both the DB and DBX, its execution is denied.
That being said, if you want to protect your systems against the BootHole vuln, and the march 2021 one, you have (at least) two options :
- Your system will never ever need to run something else than a legitimate Windows copy : you can safely remove the UEFI CA 2011 entry in the DB. Your system will only be able to boot Microsoft Windows bootloaders
- You want to be able to install another OS, and keep the Secure Boot mecanism enabled : in this case, as you did, you need to update the DBX to specifically disallow the bootloaders concenred by the vulns. This is the update process described in the KB article you linked. As the process will only touch the DBX, you will retian the ability to boot non-vulnerable Linux bootloaders in the future (even when using a Live USB)
Hope this is helpful, some concepts around the Secure Boot process can be quite cryptic sometimes :)
Best regards,
Florian Stosse
Information security engineer
Safran Electronics & Defense | Safran Data Systems | Space & Communication
Phone: +33 1 69 82 79 43 • Mobile : +33 6 48 11 16 12
Safran Data Systems
5, avenue des Andes - CS 90101
91978 Courtaboeuf Cedex, France
De : ntsys...@googlegroups.com <ntsys...@googlegroups.com> De la part de Mayo, Bill
Envoyé : lundi 12 avril 2021 17:40
À : ntsys...@googlegroups.com
Objet : [ntsysadmin] Boothole fix
--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/5a941b19a9314a15ae73002b504b90e5%40pittcountync.gov.
" Ce courriel et les documents qui lui sont joints peuvent contenir des informations confidentielles, être soumis aux règlementations relatives au contrôle des exportations ou ayant un caractère privé. S'ils ne vous sont pas destinés, nous vous signalons qu'il est strictement interdit de les divulguer, de les reproduire ou d'en utiliser de quelque manière que ce soit le contenu. Toute exportation ou réexportation non autorisée est interdite Si ce message vous a été transmis par erreur, merci d'en informer l'expéditeur et de supprimer immédiatement de votre système informatique ce courriel ainsi que tous les documents qui y sont attachés."
******
" This e-mail and any attached documents may contain confidential or proprietary information and may be subject to export control laws and regulations. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. Unauthorized export or re-export is prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system."
#
Mayo, Bill
Thank you for this information. The article seems to suggest that the GetString returning TRUE means that you are vulnerable, but it sounds like you are saying that is not true. In our cases, Nessus scans continue to show the system as being vulnerable, which seemed to corroborate what my original understanding is.
I believe I understand what you are saying in the 2 bullet points, but I have never seen anything that indicates how you would remove that record. Is that documented somewhere?
From: ntsys...@googlegroups.com <ntsys...@googlegroups.com>
On Behalf Of STOSSE Florian (SAFRAN ELECTRONICS & DEFENSE)
Sent: Wednesday, April 14, 2021 3:47 PM
To: ntsys...@googlegroups.com
Subject: [ntsysadmin] RE: Boothole fix
Hi,
The GetString always returning True is the expected behavior, even after having applied the update.
The Secure Boot process relies on several cryptographical parts (the Platform Key, one or more Key Exchange Keys, the allow database and the deny database). By default, when you buy a new machine, say from Dell or any manufacturer, the Platform Key is provided by the manufacturer. If you bought it with an active Windows license, you also get at least 2 Key Exchange Keys :
- The manufacturer KEK
- The Microsoft KEK used to sign legitimate Windows bootloaders
These KEK are used to sign the DB (allow) and DBX (deny) databases. By default, the DB contains the 'Microsoft Corporation UEFI CA 2011' entry, that tells the Secure Boot process that any bootloader signed by this Certificate Authority is allowed to boot. This authority is used by Microsoft to sign third party bootloaders, such as the shims used to launch the Grub bootloader (cf. https://wiki.ubuntu.com/UEFI/SecureBoot/ShimUpdateProcess)
In the Secure Boot process, the DBX takes priority over the DB, meaning that if a CA or a SHA256 (you can use a hash to specifically allow/disallow a bootloader or a driver) is listed in both the DB and DBX, its execution is denied.
That being said, if you want to protect your systems against the BootHole vuln, and the march 2021 one, you have (at least) two options :
- Your system will never ever need to run something else than a legitimate Windows copy : you can safely remove the UEFI CA 2011 entry in the DB. Your system will only be able to boot Microsoft Windows bootloaders
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/ec5d0bf18dec4905aec619b7ce437e5c%40Y0032SY.rd1.rf1.
Mayo, Bill
In case there was anyone interested or experiencing a similar problem, I have finally come to some conclusions here. Based on comments from the thread I mentioned below, I executed the following 3 commands on servers after applying the fix:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Canonical Ltd. Master Certificate Authority'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Debian Secure Boot CA'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Virtual UEFI Root CA'
What I found was that I had varying results on different servers, with some mixed results of “true” and “false” for the commands. I determined that if all 3 returned “true”, the vulnerability would clear from the Nessus scan. I also found that if I re-ran the “Set-SecureBootUefi -Name dbx -ContentFilePath .\content.bin -SignedFilePath .\signature.p7 -Time 2010-03-06T19:17:21Z -AppendWrite” command, the results from the above would improve. In some cases running it twice worked, and in other cases I had to run it 3 times.
An interesting note is that Eclypsium provides a script to check for the revoked files at https://github.com/eclypsium/BootHole/. This script would report no issues even when the Nessus scan still indicated there was a problem.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/84a0925205da4273bff15f9c011dfb4a%40pittcountync.gov.