MSI has very insecure Secure Boot defaults #322
Replies: 72 comments 3 replies
-
|
What loader is 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. |
Beta Was this translation helpful? Give feedback.
-
|
@medhefgo The issue is that I found all of this too weird to not have an issue about it. EDIT:
Yes, the chat log included the |
Beta Was this translation helpful? Give feedback.
-
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: memtest86plus/memtest86plus#201 (comment) (in that case always being enabled and working).
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… |
Beta Was this translation helpful? Give feedback.
-
|
Here is a bunch of runs I just did: Run 0Secure Boot enabled with factory keys.
Run 1Changed Secure Boot Mode to Custom and showing all keys enrolled.
Run 2Disabled Secure Boot. This one is kinda interesting, cause I remember disabling SB and still OS behaving as if it still was enabled.
Run 3Clearing Secure Boot keys.
Run 4When 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 5Trying to remove just PK, it… doesn't do anything. Maybe it would be able to delete non-factory key, but idk.
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:
It's systemd-boot and it's not signed. |
Beta Was this translation helpful? Give feedback.
-
|
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:
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… |
Beta Was this translation helpful? Give feedback.
-
|
Is there a reliably way to detect motherboard versions from Linux? I'm contemplating if |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Unless RebeccaBlackOS has Secure Boot support, I think that's pretty unlikely. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Well, you told me boot something from a USB and I'm just saying that I did that.
Will try later. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
Are you sure that was an UEFI boot and not CSM? Cause the iso does not have a EFI directory. |
Beta Was this translation helpful? Give feedback.
-
|
Shouldn't Secure Boot decline it anyway? But okay, Arch Linux and Void My understanding is that GRUB shouldn't even boot if Secure Boot was |
Beta Was this translation helpful? Give feedback.
-
|
I just tried every firmware available from MSI's website. They all have |
Beta Was this translation helpful? Give feedback.
-
|
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.
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:
|
Beta Was this translation helpful? Give feedback.
-
|
I know that it is a case for some MSI boards, but according to fwupdmgr, |
Beta Was this translation helpful? Give feedback.
-
|
That's curious. If you are able to source CSME System Tools for v16+ you could try running |
Beta Was this translation helpful? Give feedback.
-
|
Welp, tried v16 and told me that Raptor Lake is unsupported, only Alder Lake. |
Beta Was this translation helpful? Give feedback.
-
|
You can see it with Fedora 37 and Fedora 38 Rawhide that the Intel Management Engine is located Manufacturing Mode. |
Beta Was this translation helpful? Give feedback.
-
|
This is a different board and this info comes from fwupd. |
Beta Was this translation helpful? Give feedback.
-
|
Please keep in mind this issue is for Secure Boot issues. Manufacture mode, general other issues with MSI stuff isn't really relevant. The issue has been linked many places at the moment, please keep it on-track :) |
Beta Was this translation helpful? Give feedback.
-
|
Btw turning those 3 into always deny result in msi b550 gaming wifi edge cannot boot at all. Can't even go to uefi |
Beta Was this translation helpful? Give feedback.
-
|
@orangpelupa Don't use Always Deny. It means that it will ALWAYS DENY, no matter if it's signed or not. You want "Deny Execute". Clear CMOS and do it properly. |
Beta Was this translation helpful? Give feedback.
-
Whoops my bad. Btw maybe make a clear warning to the OP? In case other people did the same mistake as me. Corrextion, clear cmos does fix the problem. |
Beta Was this translation helpful? Give feedback.
-
|
MSI has released a beta firmware update for the MEG X570S UNIFY-X MAX 7D51v151. The output I got when I ran the script above was "7D51v151: Good". However, I had to take that script and modify it for Kali Linux. Since I'm a firm believer in "Trust but verify", does anyone else who is using the script get the same outcome when they run it on that firmware package? |
Beta Was this translation helpful? Give feedback.
-
Idk how you ran the script, maybe you don't have some of the tools Anyway, the script is outdated as it doesn't work for newer firmware |
Beta Was this translation helpful? Give feedback.
-
|
Well, I'm glad I asked. I was afraid it was too good to be true. Thank you for following up. |
Beta Was this translation helpful? Give feedback.
-
|
If anyone following this issue wants to help Richard on the recent MSI leak please read. https://blogs.gnome.org/hughsie/2023/05/09/msi-and-insecure-kms/ |
Beta Was this translation helpful? Give feedback.
-
|
Firmware: ‼ Your firmware has known quirks still shows after I set Maximum Security in the bios this normal? thanks |
Beta Was this translation helpful? Give feedback.
-
|
This is expected, we can't tell from the OS side what settings you have set. |
Beta Was this translation helpful? Give feedback.
-
|
@dawidpotocki I was looking for the execution policy on b450-tomahawk and b550m-mortart, Do you know if they removed image execution policy and just made two options, hardware/os compatibility and maximum security? https://www.msi.com/Motherboard/B450-TOMAHAWK/support |
Beta Was this translation helpful? Give feedback.
-
|
looks like they did, they made it so much harder to understand lul |
Beta Was this translation helpful? Give feedback.
-
|
Like it is mentioned at the top, it has been renamed. Hardware/OS compatibility means "pretend that we are doing anything" and Maximum Security actually does verification checks. |
Beta Was this translation helpful? Give feedback.
-
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:
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.
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 statusand noticed thatwhile Secure Boot was enabled, Setup Mode was disabled and Microsoft was
still enrolled.
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:
Later tried to sign all EFI binaries with my unenrolled keys and… it
still booted.
Beta Was this translation helpful? Give feedback.
All reactions