Support including official Microsoft DBX when including Microsoft keys

[harmonicoscillator]

When using the -m option, Microsoft's DB keys are downloaded, signed with the new local keys, and included for sync with the firmware in order to allow critical Microsoft signed binaries (like GPU GOPs or a dual-booted Windows installation) to be loaded. However, the associated DBX list of forbidden checksums, available from https://uefi.org/revocationlistfile , is not included. If the DBX file is not installed, I believe this creates a security issue where a binary signed by Microsoft's DB and also in the DBX (like Grub2 versions affected by the boothole vulnerability) could be booted, breaking the security guarantees of Secure Boot.

Is it possible to include the official DBX when using the -m option? I believe that this would require stripping the Microsoft signature from the official DBX file and re-signing with the local keys. Syncing the DBX could done with the dbxtool utility by end users. I'm unsure if sbkeysync supports automatic handling of DBX or not.

It would also be very beneficial to include instructions on how to update the DBX when using already-generated keys from a previous invocation of sbkeys. In particular, stripping the MS signature from the DBX file seems nontrivial. (An extension to sbkeys that might handle this automatically would be great but I understand if it is out-of-scope.)

Please correct me if my understanding of the interaction between the Microsoft DB and DBX is incorrect.

[harmonicoscillator]

This SO post seems to have relevant context for stripping the MS signature from the DBX file: https://unix.stackexchange.com/questions/601093/how-to-update-the-dbx-variable-having-the-uefi-revocation-list-file

[harmonicoscillator]

Here is the method I was able to use to add the DBX file to my efivars, based on the advice from this blogpost: https://blog.uncooperative.org/uefi/linux/secure%20boot/2014/10/23/uefi-security-databases.html

1. Download the latest x64 version of the revocation list from https://uefi.org/revocationlistfile
2. Use a hex editor to search for the value c1c41626-504c-4092-aca9-41f936934328, which is EFI_GUID_SHA256 (I think) and marks the end of the original authentication section. Note the location of that entry. In the case of the 2021-04-29 DBX release, it is 3345.
3. Strip out the first 3345 bytes from the file to remove the Microsoft signature using dd: dd if=dbxupdate_x64.bin of=dbxupdate_x64.esl bs=1 skip=3345
4. Use your own personal keys to re-sign the extracted esl: sbvarsign --key /etc/efi-keys/KEK.key --cert /etc/efi-keys/KEK.crt dbx dbxupdate_x64.esl --output dbxupdate_x64_varsign.auth
5. Double check that the resulting file is valid with dbxtool: dbxtool --dbx dbxupdate_x64_varsign.auth --list. It should output a list of forbidden signatures. If you used the wrong value when stripping the MS signature out, you should not get a list of signatures.
6. Add the signature list to the dbx var with dbxtool: dbxtool --apply dbxupdate_x64_varsign.auth --verbose

A few notes:

• For some reason when I tried to use sign-efi-sig-list to generate the .auth version of the dbx update, none of the usual efi update programs could successfully apply the resulting auth file to the efivars, I just kept getting either Permission Denied or Invalid Argument errors. I tried using sbkeysync, dbxtool, efi-updatevar, and KeyTool.efi and none worked. This might be specific to my platform, or maybe I didn't use the right secret sauce to sign DBX files. Using sbvarsign worked first try uploading with dbxtool.
• Updating the value of the DBX var also changed the values of my PCR 7 register, which meant my systemd-cryptenroll LUKS TPM keys were no longer valid which was annoying. I wasn't expecting that.
• I do not have the skills to write a consistent script to strip the Microsoft signature from the original file. Hopefully someone can provide one for when it is inevitably updated :pray:

[justinkb]

you can use this for that purpose https://www.powershellgallery.com/packages/SplitDbxContent/1.0

use Windows PowerShell, not PowerShell Core

PS. I'm fairly sure you got Permission Denied because the update on uefi.org is signed with the microsoft kek, which you probably do not have enrolled?