search

Foxboron / sbctl

:computer: :lock: :key: Secure Boot key manager
MIT License
1.5k stars 86 forks source link

MSI has very insecure Secure Boot defaults #181

Closed dawidpotocki closed 4 months ago

dawidpotocki commented 1 year ago

Some MSI motherboards with some firmware versions by default allow booting binaries on policy violations, thereby not providing any additional security compared to having Secure Boot disabled. Scroll down for a list of affected boards and their firmware versions.

To deny booting on policy violation, go to the place where your Secure Boot settings are in your UEFI, change "Secure Boot Mode" to "Custom" and then open "Image Execution Policy".

Some example locations:

NOTE: MSI released beta firmware for some AMD and Intel boards and the layout looks different. Instead of "Image Execution Policy" there is a "Secure Boot Preset" option with "Hardware/OS Compatibility" and "Maximum Security", pick "Maximum Security".

Then change "Always Execute" to "Deny Execute" on "Removable Media" and "Fixed Media". Optionally you can also change "Option ROM" to "Deny Execute", read more about Option ROMs:

WARNING: DON'T USE "ALWAYS DENY" UNLESS YOU KNOW WHAT YOU ARE DOING. Use "Deny Execute" instead.

Example UEFI firmware screenshots: ![Example screenshot 1](https://user-images.githubusercontent.com/38681822/210061768-a6d85e27-5e5e-48a5-a5b6-2a1ec77240b4.png) ![Example screenshot 2](https://user-images.githubusercontent.com/38681822/210061788-6c2b223a-4bae-416b-81db-39fdba2bb173.png)

My blog post in English: https://dawidpotocki.com/en/2023/01/13/msi-insecure-boot/ Mój post na blogu po polsku: https://dawidpotocki.com/pl/2023/01/13/msi-insecure-boot/

MSI's statement: https://www.reddit.com/r/MSI_Gaming/comments/10g9v3m/msi_statement_on_secure_boot/

Format:

Some build dates are earlier than release dates, don't ask me why.

MSI firmware shows dates in MM/DD/YYYY, I have provided them in YYYY-MM-DD.

Affected motherboards (all firmware versions):

Affected motherboards (newer firmware versions):

Unaffected motherboards (so far):

No downloadable firmware available, need volunteers

Original issue

Title: MSI PRO Z790-A has very broken Secure Boot

Submitting as Foxboron asked me to. > Feel free to open an issue on sbctl and we can keep track of it Chat log: https://view.matrix.org/room/!GtIfdsfQtQIgbQSxwJ:archlinux.org/?anchor=$smbsrKoEbpAzdUlEfGDSA-StHWVsoVbotfH06e3lVXs&offset=120 The board seems to accept unsigned OSes when booting with Secure Boot enabled. Firmware version: E7E07IMS.A22 (7E07vA2). This is how it went: I went to firmware to enable Secure Boot and also wiped factory keys to switch into Setup Mode. Then I checked `sbctl status` and noticed that while Secure Boot was enabled, Setup Mode was disabled and Microsoft was still enrolled. ``` $ sbctl status Installed: ✓ sbctl is installed Owner GUID: 6e2b1be3-6ecf-41e6-a59b-a30efdfa85ba Setup Mode: ✓ Disabled Secure Boot: ✓ Enabled Vendor Keys: microsoft ``` Well that made no sense. I went back to firmware and toggled "Custom" mode to "Standard" or something like that. Well… still booting. Here is the output of commands that I was asked to run: ``` $ efi-readvar -v db Variable db, length 3961 db: List 0, type X509 Signature 0, size 790, owner 841d6484-c82e-4135-ac79-0bf5d26284cd Subject: CN=MSI SHIP DB Issuer: CN=MSI SHIP KEK db: List 1, type X509 Signature 0, size 1572, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011 Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root db: List 2, type X509 Signature 0, size 1515, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011 Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010 ``` ``` $ efibootmgr -v BootCurrent: 0000 Timeout: 0 seconds BootOrder: 0000,0001 Boot0000* Linux Boot Manager HD(1,GPT,eee220d1-aec3-45fa-adf2-596981dc70e1,0x800,0x100000)/File(\EFI\systemd\systemd-bootx64.efi) dp: 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 00 10 00 00 00 00 00 d1 20 e2 ee c3 ae fa 45 ad f2 59 69 81 dc 70 e1 02 02 / 04 04 46 00 5c 00 45 00 46 00 49 00 5c 00 73 00 79 00 73 00 74 00 65 00 6d 00 64 00 5c 00 73 00 79 00 73 00 74 00 65 00 6d 00 64 00 2d 00 62 00 6f 00 6f 00 74 00 78 00 36 00 34 00 2e 00 65 00 66 00 69 00 00 00 / 7f ff 04 00 Boot0001* UEFI OS HD(1,GPT,eee220d1-aec3-45fa-adf2-596981dc70e1,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f dp: 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 00 10 00 00 00 00 00 d1 20 e2 ee c3 ae fa 45 ad f2 59 69 81 dc 70 e1 02 02 / 04 04 30 00 5c 00 45 00 46 00 49 00 5c 00 42 00 4f 00 4f 00 54 00 5c 00 42 00 4f 00 4f 00 54 00 58 00 36 00 34 00 2e 00 45 00 46 00 49 00 00 00 / 7f ff 04 00 data: 00 00 42 4f ``` ``` $ sbverify --list /efi/EFI/systemd/systemd-bootx64.efi warning: data remaining[110080 vs 121365]: gaps between PE/COFF sections? warning: data remaining[110080 vs 121368]: gaps between PE/COFF sections? No signature table present ``` ``` $ fwupdmgr update WARNING: UEFI capsule updates not available or enabled in firmware setup See https://github.com/fwupd/fwupd/wiki/PluginFlag:capsules-unsupported for more information. Devices with no available firmware updates: • 0000:00:1f.5 • CT2000P5PSSD8 ╔══════════════════════════════════════════════════════════════════════════════╗ ║ Upgrade UEFI dbx from 77 to 217? ║ ╠══════════════════════════════════════════════════════════════════════════════╣ ║ This updates the dbx to the latest release from Microsoft which adds ║ ║ insecure versions of grub and shim to the list of forbidden signatures due ║ ║ to multiple discovered security updates. ║ ║ ║ ║ Before installing the update, fwupd will check for any affected executables ║ ║ in the ESP and will refuse to update if it finds any boot binaries signed ║ ║ with any of the forbidden signatures. If the installation fails, you will ║ ║ need to update shim and grub packages before the update can be deployed. ║ ║ ║ ║ Once you have installed this dbx update, any DVD or USB installer images ║ ║ signed with the old signatures may not work correctly. You may have to ║ ║ temporarily turn off secure boot when using recovery or installation media, ║ ║ if new images have not been made available by your distribution. ║ ║ ║ ╚══════════════════════════════════════════════════════════════════════════════╝ Perform operation? [Y|n]: ``` Later tried to sign all EFI binaries with my unenrolled keys and… it still booted.
medhefgo commented 1 year ago

What loader is \EFI\BOOT\BOOTX64.EFI and is it signed? Also, does bootctl agree on secure boot state?

MSI firmware is pretty much identical to ASUS, so these instructions should work for you: https://github.com/Foxboron/sbctl/blob/master/docs/workflow-example.md. You can even make screenshots with F12 (it should ask you for a usb stick to store them onto), which may help us figuring out if everything is set up correctly.

Foxboron commented 1 year ago

@medhefgo The issue is that BOOTX64.EFI is not being booted, and it apparently boots the unsigned sd-boot binary.

I found all of this too weird to not have an issue about it.

EDIT:

Also, does bootctl agree on secure boot state?

Yes, the chat log included the bootctl output and it said SB is enabled.

medhefgo commented 1 year ago

Yes, the chat log included the bootctl output and it said SB is enabled.

That chatlog is terrible and I cannot find the bootctl output. I'll take your word for it.

It seems that MSI has other boards with weird secure boot issues: https://github.com/memtest86plus/memtest86plus/issues/201#issuecomment-1328354576 (in that case always being enabled and working).

I went to firmware to enable Secure Boot and also wiped factory keys to switch into Setup Mode. Then I checked sbctl status and noticed that while Secure Boot was enabled, Setup Mode was disabled and Microsoft was still enrolled.

Was this done in one step or with a save and reset in between? Does the secure boot menu explicitly state that secure boot is disabled after clearing the keys (before leaving the firmware setup)? Have you tried only deleting the PK while leaving the others keys as is?

Resetting firmware settings and/or downgrading/reflashing the firmware might be something to try…

dawidpotocki commented 1 year ago

Here is a bunch of runs I just did:

Run 0

Secure Boot enabled with factory keys.

Run 0, Firmware 0 Run 0, OS 0

Run 1

Changed Secure Boot Mode to Custom and showing all keys enrolled.

Run 1, Firmware 0 Run 1, Firmware 1 Run 1, Firmware 2 Run 1, Firmware 3 Run 1, Firmware 4 Run 1, OS 0

Run 2

Disabled Secure Boot. This one is kinda interesting, cause I remember disabling SB and still OS behaving as if it still was enabled.

Run 2, Firmware 0 Run 2, Firmware 1 Run 2, OS 0

Run 3

Clearing Secure Boot keys.

Run 3, Firmware 0 Run 3, Firmware 1 Run 3, OS 0

Run 4

When checking enrolled keys, factory keys were back. This time when clearing keys I didn't just press "Yes" when clearing keys. I checked enrolled keys and noticed that there is an option to automatically enroll factory keys… oh well. I didn't notice it earlier as I was focused on keys showing that there is nothing there and popup telling me that it will put me in Setup Mode. Disabled that and it worked. My bad, but MSI should have designed their firmware better.

Run 4, Firmware 0 Run 4, Firmware 1 Run 4, Firmware 2 Run 4, Firmware 3 Run 4, OS 0

Run 5

Trying to remove just PK, it… doesn't do anything. Maybe it would be able to delete non-factory key, but idk.

Run 5, Firmware 0 Run 5, Firmware 1 Run 5, OS 0

Soon™

I will try reflashing firmware and downgrading, but not today. I tried changing some settings that I changed back to defaults to check if they caused this issue, but no. I didn't change much, mostly just memory speed, timings and fan settings.

EDIT:

What loader is \EFI\BOOT\BOOTX64.EFI and is it signed?

It's systemd-boot and it's not signed.

dawid@archlinux in ~
$ sbverify --list /efi/EFI/systemd/systemd-bootx64.efi
warning: data remaining[110592 vs 121739]: gaps between PE/COFF sections?
warning: data remaining[110592 vs 121744]: gaps between PE/COFF sections?
No signature table present
dawid@archlinux in ~
$ sbverify --list /efi/EFI/BOOT/BOOTX64.EFI
warning: data remaining[110592 vs 121739]: gaps between PE/COFF sections?
warning: data remaining[110592 vs 121744]: gaps between PE/COFF sections?
No signature table present
medhefgo commented 1 year ago

Well, that is some interesting firmware…

Have you tried enrolling your own keys when in setup mode? And does that properly activate signature checking?

I have two working theories right now:

  1. The firmware might be trusting your efi binaries on a TOFU basis on first boot after clearing the keys. Easily tested by swapping out to a different build/version of sd-boot after booting once.
  2. The firmware might be thinking your boot hd is a trusted firmware volume and therefore does not enforce signatures. If that is the case it might refuse booting unsigned images from a usb stick (ideally different from the ones on the ESP).

If possible, you could also try moving the ESP to a different internal drive. I'm also wondering if it would accept efi binaries coming from a XBOOTLDR partition…

Foxboron commented 1 year ago

Is there a reliably way to detect motherboard versions from Linux? I'm contemplating if sbctl should have a generic "wonkey warning" if it encounters known bad motherboard+firmware versions.

medhefgo commented 1 year ago

Is there a reliably way to detect motherboard versions from Linux? I'm contemplating if sbctl should have a generic "wonkey warning" if it encounters known bad motherboard+firmware versions.

DMI/SMBIOS info is the best source you're looking for (demidecode). And even that is full of "to be filled by OEM" crap that has to be filtered out. Best thing is to access it by hostnamectl (or hostnamed dbus API) as it does that for you.

dawidpotocki commented 1 year ago

The firmware might be thinking your boot hd is a trusted firmware volume and therefore does not enforce signatures. If that is the case it might refuse booting unsigned images from a usb stick (ideally different from the ones on the ESP).

Unless RebeccaBlackOS has Secure Boot support, I think that's pretty unlikely.

medhefgo commented 1 year ago

Unless RebeccaBlackOS has Secure Boot support, I think that's pretty unlikely.

The firmware not checking the signature has nothing to do with your OS. And firmwares are known to do silly things, and confusing the ESP as an internally trusted firmware volume is something I wouldn't put past them.

It would also be interesting to see if it will at least handle the blocklist correctly by trying to boot a signed shim that is on the blocklist. Which version to try is a different question though, but one from like 2 years ago or so along with the dbx update should suffice.

dawidpotocki commented 1 year ago

The firmware not checking the signature has nothing to do with your OS.

Well, you told me boot something from a USB and I'm just saying that I did that.

It would also be interesting to see if it will at least handle the blocklist correctly by trying to boot a signed shim that is on the blocklist.

Will try later.

medhefgo commented 1 year ago

Well, you told me boot something from a USB and I'm just saying that I did that.

That was a rather roundabout way of saying that.

For shim testing, make sure that the dbx update has been applied again (because it gets cleared when sb vars are reset). Then make an entry that points to the shim binary with a copy of you loader (I recommend an efi shell) named to grubx64.efi next to it. A quick test on my machine says that this one is old enough to get rejected: https://kojipkgs.fedoraproject.org//vol/fedora_koji_archive05/packages/shim/13/2/x86_64/shim-x64-13-2.x86_64.rpm

medhefgo commented 1 year ago

Well, you told me boot something from a USB and I'm just saying that I did that.

Are you sure that was an UEFI boot and not CSM? Cause the iso does not have a EFI directory.

dawidpotocki commented 1 year ago

Shouldn't Secure Boot decline it anyway? But okay, Arch Linux and Void Linux iso will start GRUB, but GRUB will complain that shim lock is not available when picking an entry and will not start the OS.

error: shim_lock protocol not found
error: you need to load kernel first

My understanding is that GRUB shouldn't even boot if Secure Boot was working, so it's just GRUB expecting to be signed or used with a shim and failing.

dawidpotocki commented 1 year ago

I just tried every firmware available from MSI's website. They all have Secure Boot broken.

https://www.msi.com/Motherboard/PRO-Z790-A-WIFI/support

dawidpotocki commented 1 year ago

I found the solution and I hate it.

By default MSI sets "Always execute" on policy violation on everything, essentially making Secure Boot useless with the default settings. This shouldn't be the default. Also "Query user" is useless if user is using some type of a bootloader, as it won't accept input anymore.

image

EDIT: Maybe sbctl should warn people on MSI motherboards about this setting? It makes people have a false sense of security.

To change it you have to:

  1. Set Secure Boot Mode to "Custom"
  2. Open "Image Execution Policy"
  3. Change policies to "Deny Execute".
medhefgo commented 1 year ago

EDIT: Maybe sbctl should warn people on MSI motherboards about this setting? It makes people have a false sense of security.

It should. And it's probably prudent to do so for all MSI firmware that claim to be UEFI 2.80 and not just for this board/firmware.

  1. Set Secure Boot Mode to "Custom"

Out of curiosity, what are the options for secure boot mode (I assume standard, custom and disabled)? From what I can tell, keys and execution policy can only be changed when set to custom?

These screenshots should be turned into another guide by someone (I am feeling lazy :D).

Also, I strongly suggest to keep OptionROM at always execute. Removable media should also be deny execute or malware has an easy attack vector as long as a usb drive is plugged in.

dawidpotocki commented 1 year ago

I just asked someone with an MSI B450 TOMAHAWK MAX to check their firmware… same options by default. It looks like it isn't exclusive to my board. Though not sure when it was introduced.

MSI B450 TOMAHAWK MAX firmware

dawidpotocki commented 1 year ago

Out of curiosity, what are the options for secure boot mode (I assume standard, custom and disabled)? From what I can tell, keys and execution policy can only be changed when set to custom?

Standard and Custom. Executing Policy can only be changed in Custom.

medhefgo commented 1 year ago

What UEFI version is reported by bootctl for them?

Foxboron commented 1 year ago

This sounds extremely broken.

dawidpotocki commented 1 year ago

Their output (very fun, who doesn't love some n/a?):

$ bootctl
System:
     Firmware: n/a (n/a)

$ hostnamectl
   Hardware Vendor: Micro-Star International Co., Ltd
    Hardware Model: MS-7C02
  Firmware Version: 3.F0

Btw, with Option ROM being set to Always Execute, could people then just not bother to enroll Microsoft's key?

medhefgo commented 1 year ago

Their output (very fun, who doesn't love some n/a?):

They're not using sd-boot then. Can you ask them to use it just once so we can get to the UEFI version?

Btw, with Option ROM being set to Always Execute, could people then just not bother to enroll Microsoft's key?

That's my expectation, yes.

medhefgo commented 1 year ago

(There's no need to create a boot entry, btw. The UEFI version is also listed when you press p in the sd-boot menu.)

medhefgo commented 1 year ago

2. The firmware might be thinking your boot hd is a trusted firmware volume and therefore does not enforce signatures. If that is the case it might refuse booting unsigned images from a usb stick (ideally different from the ones on the ESP).

I just realized that one of my theories was correct. Yay me. :joy_cat:

Foxboron commented 1 year ago

That sounds like a terrible default though. Glad we got it documented.

dawidpotocki commented 1 year ago

They're not using sd-boot then. Can you ask them to use it just once so we can get to the UEFI version?

Firmware: UEFI 2.70 (American Megatrends 5.17)
medhefgo commented 1 year ago

So, considering that the UEFI spec version is hard to get by unless sd-boot (or sd-stub) is used, one could probably use the BIOS revision field from dmidecode for that if the board vendor is MSI as those versions seem to get incremented in tandem.

dawidpotocki commented 1 year ago

I got more information from another user of a B450 TOMAHAWK MAX. The affected firmware on this board is 7C02v3C from 2022-01-18. 7C02v3B from 2021-05-25 doesn't have the "Image Execution Policy" option and will give an image execution violation message.

The bad news is that the changelog mentions NOTHING about this change. So it might be hard to get the list of all affected boards, but I suspect that every firmware from 2022 onwards is affected. I found some patterns in changelogs and firmware versions, but need confirmation. Would need more volunteres with different boards to pin point the exact date and firmware.

7C02v3C Description:

  • Update to ComboAM4PIV2 1.2.0.5

Now, the output from bootctl and hostnamectl. As we can see, we can't rely on AMI version. This isn't very surprising to me as I was able to find Asus and MSI manuals from 2013 with "Image Execution Policy" mentioned. So this option has been available for a long time, it just was hidden from us.

7C02v3C

Firmware Version: 3.C0
Firmware: UEFI 2.70 (American Megatrends 5.17)

7C02v3B

Firmware Version: 3.B0
Firmware: UEFI 2.70 (American Megatrends 5.17)

I have updated the issue with a list of mobos and firmware that I believe to be affected.

josephlr commented 1 year ago

I have a B550-A-PRO-CEC motherboard, and I can confirm that AMI BIOS version 7C56vH4 has this issue. The default image execution policy is "Always Execute" even when the Secure Boot mode is "Standard".

I would assume the B550-A-PRO BIOS version 7C56vAB also has this issue as they are just different names for the same BIOS.

The BIOS changelog has a suspicious entry:

Change the default setting of Secure Boot.

I'm wondering if that's the change which caused all these problems.

josephlr commented 1 year ago

I did a little more digging into EDK2 to figure out which settings were causing the issue. The invalid settings here seem to be the following PCD values:

As noted in that code, the default value should be 0x04 (Deny execution when there is security violation), but instead MSI sets the default value to 0x00 (Always trust the image).

Microsoft put out UEFI Validation Option ROM Guidance, which talks about security issues around having PcdOptionRomImageVerificationPolicy be 0x00. Firmware vendors also setting 0x00 for external images is significantly worse (than the issue described in that article).

dawidpotocki commented 1 year ago

I have a B550-A-PRO-CEC motherboard, and I can confirm that AMI BIOS version 7C56vH4 has this issue. The default image execution policy is "Always Execute" even when the Secure Boot mode is "Standard".

Thank you for this information. Did you check any previous version? I suspect that 7C56vH1 might also be affected and that 7C56vH0 isn't.

The BIOS changelog has a suspicious entry:

Change the default setting of Secure Boot.

I'm wondering if that's the change which caused all these problems.

I thought the same, but some boards have this issue in versions preceding firmware with that changelog. From what I can tell some versions introduced this issue with changelog that has "Windows 11 support" and for some other boards it would be versions following firmware that has changelog with "Improved USB device compatibility".

josephlr commented 1 year ago

Thank you for this information. Did you check any previous version? I suspect that 7C56vH1 might also be affected and that 7C56vH0 isn't.

This turned out to be exactly correct. 7C56vH0 didn't have the issue (or the "Image Execution Policy" submenu), but 7C56vH1 did. Looks like the "Support Windows 11" stuff was the culprit.

Foxboron commented 1 year ago

This is a bit funny. It might be related to the disablement of the 3rd party UEFI certificate and Secured Core PC certification that became a thing with Windows 11? (speculation of course).

https://mjg59.dreamwidth.org/60248.html

EDIT: It might be interesting to see if the different firmwares handles the 3rd party certificate?

josephlr commented 1 year ago

It might be interesting to see if the different firmwares handles the 3rd party certificate?

At least for my motherboard, the default configuration for all versions includes both certificates in the db (the Windows one and the third-party one). So I don't think changing the default certificate configuration was related to this issue.

Foxboron commented 1 year ago

Cool, thanks for checking!

dawidpotocki commented 1 year ago

Now that I'm back home, I spent some time to figure out how to extract data from their firmware files.

I updated the issue with all the firmware versions I verified so far to be affected, but there is still few of them left. Some motherboards don't have firmware available on their website, so there is no way for me to check these boards.

I have checked some recent MSI laptops, they don't seem to be affected.

I have also checked other motherboard makers like ASRock, ASUS, Biostar, EVGA, Gigabyte and NZXT. I didn't find any such option on their mobos, but I have found a mention of "Audit" mode setting on EVGA and Gigabyte boards, though I don't think that this option is enabled by default.

Foxboron commented 1 year ago

Generally speaking; shouldn't this have CVEs assigned? Breaking Secure Boot is quite bad frankly, and not something people would expect.

dawidpotocki commented 1 year ago

From what I can see, there are a bunch of CVEs for insecure defaults.

Like this for example: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18579

If this qualifies as a CVE, this probably does too.

If you think that this is a good idea, I can submit it when I finish up the list of vulnerable firmware versions.

Foxboron commented 1 year ago

I think it would be a good idea.

If you also document how you are validating firmware that would be ideal :)

dawidpotocki commented 1 year ago

Ah right, forgot to say how I did this 😅.

Basically I found out that UEFI has a thing called "UEFI Internal Form Representation" or in short "IFR".

So I just used UEFIExtract from UEFITool to extract stuff from the firmware file and then I ran IFRExtractor RS on the Setup file named Section_PE32_image_899407D7-99FE-43D8-9A21-79EC328CAC21_Setup_body.bin (all vendors seem to have the same UUID, though iirc ASUS didn't have Setup in the name) which contains most of UEFI GUI stuff. Then I greped it for the Image Execution Policy and checked if its default value is set to 0x0 which equals to "Always Execute".

From what I understand, use of IFR is not required by UEFI spec, so it might not work everywhere, but from my own tests, all major desktop motherboard makers use it.

#!/bin/sh

if [ ! -d "$1" ]; then
    [ ! -f "$1.zip" ] && curl "https://download.msi.com/bos_exe/mb/$1.zip" -O -#
    bsdtar xf "$1.zip"
fi

cd "$1" || exit
UEFIExtract ./*MS.* unpack 1>/dev/null
ifrextractor ./*.dump/Section_PE32_image_899407D7-99FE-43D8-9A21-79EC328CAC21_Setup_body.bin 1>/dev/null
output="$(grep -A1 -E 'OneOf Prompt: "(Option ROM|Removable Media|Fixed Media)", Help: "Image Execution Policy' ./*.dump/Section_PE32_image_899407D7-99FE-43D8-9A21-79EC328CAC21_Setup_body.bin.*ifr.txt)"
clear

if echo "$output" | grep -q "DefaultId: 0x0"; then
    printf "\033[1;31m%s: Bad\033[0m\n" "$1"
else
    printf "\033[1;32m%s: Good\033[0m\n" "$1"
fi

I feel kinda dumb that I was struggling with this for more time than was necessary, but oh well.

dawidpotocki commented 1 year ago

I… did it. I finished the list. I'm tired. Why did no PC building guide tell me that I will have to do this? I wouldn't build my first PC if I knew this.

Some fun statistic:

# The amount of times I ran the script
$ history 0 | grep "  msi " | wc -l
1989

Now, I think I should bill MSI for all the work I had to do guessing beta firmware names and figuring out this whole issue. That or they should give me a lifetime supply of motherboards.

NikoMuffin commented 1 year ago

Looks like the B550 Gaming Plus already had this fixed in recent updates?

NikolajSchlej commented 1 year ago

@dawidpotocki

Once we extract files from the firmware using UEFIExtract from UEFITool project, we can find a file called Section_PE32_image_899407D7-99FE-43D8-9A21-79EC328CAC21_Setup_body.bin. It contains most of UEFI GUI stuff and seems to be available on all firmware from all major desktop motherboard makers, though ASUS decided to remove "Setup" from the name for some reason or maybe it has to do something to do with the UEFIExtract, not sure.

The name comes from User Interface section of that FFS file with GUID 899407D7-99FE-43D8-9A21-79EC328CAC21. Some vendors decide not to provide any UI sections, so "Setup" will be missing from the name, but absolute most of them don't change the default GUID that AMI chose for their BIOS Setup app.

Now once we have this file, we have to extract IFR data from it, to do it we can use IFRExtractor RS. Funnily enough, it's made by the same people as UEFITool. Thanks guys for your hard work, otherwise I would have to do it myself ;p.

You are welcome. ;)

As for the issue discussed here, it's typical for asian OEMs that sell desktop boards for self-built PCs. All of them operate on very tight profit margins, and profit comes mostly from selling the newest possible boards for newest possible chipsets. Support for everything else is a liability, so it's done by not their best engineers and not their brightest decision makers. It looks like they've encountered an issue of "Windows 11 can't be installed by default", and fixed it in a very straightforward, but also very insecure way. The amount of support inquiries lowered, the amount of happy users with Windows 11 increased, and already broken security (believe me, that AMI-based FW was already broken in too many ways to count) became a bit more broken, but nobody from MSI side cared about that, because caring about that has zero economic sense. None of their competitors care, neither do their users. If you care about x86 PC firmware security, buy your x86 machines from Microsoft. They have a proven track record of caring about it.

heretical-blacksheep commented 1 year ago

Great work on this! Has MSI been notified and if so, have they responded?

The last time I had to deal with their tech support team I found a bug where two entries in the ESP would cause the boot process to pause and drop to the boot device dialog. This was just after Zen 1 launched. When I notified them of the bug the only response I got back was "We don't support any OS but Windows." Which was remarkably short sighted since the bug would affect Windows with two entries just as much as anyone running any other OS. I pointed that out and they never responded, but a couple or so firmware revisions later the bug magically disappeared.

I can't imagine Microsoft being pleased about this, as it would completely circumvent most of the advertised security features in Windows 11 which are built on top of secure boot being functional and enforced. The overarching question now is, how many other OEMs are breaking Secure Boot by default for whatever reason?

dawidpotocki commented 1 year ago

Looks like the B550 Gaming Plus already had this fixed in recent updates?

  • Change the default setting of Secure Boot.

No, it's still affected. This change means that they have enabled "Secure Boot" by default.

Some vendors decide not to provide any UI sections, so "Setup" will be missing from the name, but absolute most of them don't change the default GUID that AMI chose for their BIOS Setup app.

Huh! Good to know. Unfortunately it's hard to find information about this stuff if you are someone that has 0 experience with UEFI firmware.

If you care about x86 PC firmware security, buy your x86 machines from Microsoft. They have a proven track record of caring about it.

That's a fair recommendation, though unfortunately you can't just buy a motherboard from Microsoft. At least in New Zealand I don't even see their desktops, only their laptops being sold.

Great work on this! Has MSI been notified and if so, have they responded?

I have tried contacting them like 5-6 times through different methods, but they are ignoring me.

heretical-blacksheep commented 1 year ago

Unfortunately that's par for the course, it seems, with MSI. I probably won't buy another board from them.

As a quick followup, I have the X570 Gaming Plus Wifi board, which, thanks to you (and I mean that, a sincere thanks!) I revisited secure boot in the firmware UI and confirmed it has the same default values even with secure boot set to "custom".

However, when I set it to "always deny" in the Image Execution menu the board will not even POST! (Blank screen, no beep codes) So apparently there's something seriously wrong somewhere with the way MSI is doing secure boot verification at least on this particular board. The only keys involved are the factory default and Linux Mint's 3rd party keys. Right now I have the battery out of the board and waiting for cap discharge before I attempt to power it on again. Bad thing is that's my main desktop. I hope the hard reset clears the problem.

If it doesn't, I'll be looking for another board from another vendor. I'll update either way in a half hour or so.

dawidpotocki commented 1 year ago

Always Deny means always deny no matter if it's signed. What you want is Deny Execute.

heretical-blacksheep commented 1 year ago

Oops! Anyway, I managed to clear the settings, booted normally again after setting things properly this time: Custom + Deny Execute for Option, Attached, and Fixed storage. Verified that Linux Mint is booting properly and that SB was still enabled via bootctl. On top of that I did a quick download and write to a USB stick Pop!_OS which is known not to support SB and got the expected SB boot violation error when attempting to do so. I can only assume that a signed shim or kernel but without a matching key in storage will do the same as I don't have an easy way of testing that.

I don't suppose anyone knows if it's possible to change SB settings from the OS level which would make all this moot to begin with?

RhanCandia commented 1 year ago

I have MSI MAG B550M MORTAR WIFI so I had to check this one my end.

I have the latest (7C94v1D) BIOS availble from https://www.msi.com/Motherboard/MAG-B550M-MORTAR-WIFI/support In the logs they mentioned updates on the Security Settings.

7C94v1D
2022-08-19

Description:
- Update to AGESA ComboAm4v2PI 1.2.0.7.
- Change the default setting of Secure Boot.
7C94v1C
2022-06-21

Description:
- Update to AGESA ComboAm4v2PI 1.2.0.7.
- Change the default setting of Secure Boot.

In the post above it said the on MSI MAG B550M MORTAR WIFI, the affected firmware is 7C94v19 and since the two I listed above pushed changes in the settings, I was hoping it would have fixed the issue. But I was wrong.

NOTE: I did a CMOS reset before taking these.

When I went to check Secure Boot it was set to Standard and the options for Image Execution Policy was greyed out.

MSI_SnapShot

I went to set Secure Boot to Manual and checked the values inside the Execution Policy which should be in their default states.

MSI_SnapShot_00

Despite the Changes to Secure Boot settings in the last firmware version, the default values in the Execution Policy are still set to Always Execute.

I suppose for now I can set the values to the proper expected value. But which ones should I set to Deny? Removable Media and Fixed media probably, what about Option ROM? And what about the greyed out Internal FV? Should I be worried about that?

Unfortunately I can't afford to test older firmwares like 7C94v1B or 7C94v1C to see the changes introduced before what I have (7C94v1D).

dawidpotocki commented 1 year ago

Unfortunately I can't afford to test older firmwares like 7C94v1B or 7C94v1C to see the changes introduced before what I have (7C94v1D).

No need to, I already did all the testing. You can see the list in the issue.

I suppose for now I can set the values to the proper expected value. But which ones should I set to Deny? Removable Media and Fixed media probably, what about Option ROM?

Uh, it is mentioned in the issue:

Then change "Always Execute" to "Deny Execute" on "Removable Media" and "Fixed Media". Optionally you can also change "Option ROM" to "Deny Execute", read more about Option ROMs.

josephlr had also provided a link about security issues with Option ROM being set to "Always Execute". https://github.com/Foxboron/sbctl/issues/181#issuecomment-1371544441

And what about the greyed out Internal FV? Should I be worried about that?

Internal FV = Internal Firmware Volume, so it means the UEFI firmware itself. I don't think it's possible to do Secure Boot on that as firmware does the verification.