This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
MSI has very insecure Secure Boot defaults #181
Comments
|
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. |
|
@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 |
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… |
|
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. |
|
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… |
|
Is there a reliably way to detect motherboard versions from Linux? I'm contemplating if |
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. |
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. |
Well, you told me boot something from a USB and I'm just saying that I did that.
Will try later. |
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 |
Are you sure that was an UEFI boot and not CSM? Cause the iso does not have a EFI directory. |
|
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 |
|
I just tried every firmware available from MSI's website. They all have |
|
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:
|
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.
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. |
|
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.
|
Standard and Custom. Executing Policy can only be changed in Custom. |
|
What UEFI version is reported by bootctl for them? |
|
This sounds extremely broken. |
|
Their output (very fun, who doesn't love some n/a?): Btw, with Option ROM being set to Always Execute, could people then just not bother to enroll Microsoft's key? |
They're not using sd-boot then. Can you ask them to use it just once so we can get to the UEFI version?
That's my expectation, yes. |
|
(There's no need to create a boot entry, btw. The UEFI version is also listed when you press |
I just realized that one of my theories was correct. Yay me. 😹 |
|
That sounds like a terrible default though. Glad we got it documented. |
|
|
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 |
|
I got more information from another user of a B450 TOMAHAWK MAX. The The bad news is that the changelog mentions NOTHING about this change.
Now, the output from bootctl and hostnamectl. As we can see, we can't
I have updated the issue with a list of mobos and firmware that I |
dawidpotocki
changed the title
|
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: I'm wondering if that's the change which caused all these problems. |
No, it's still affected. This change means that they have enabled
Huh! Good to know. Unfortunately it's hard to find information about
That's a fair recommendation, though unfortunately you can't just buy a
I have tried contacting them like 5-6 times through different methods, |
|
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. |
|
Always Deny means always deny no matter if it's signed. What you want is Deny Execute. |
|
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? |
|
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 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.
I went to set Secure Boot to Manual and checked the values inside the Execution Policy which should be in their default states.
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? 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
Uh, it is mentioned in the issue:
josephlr had also provided a link about security issues with Option ROM being
Internal FV = Internal Firmware Volume, so it means the UEFI firmware itself. I |
|
If you look at X470 on official website there note this in changelog. With setting off you are able to install/boot archlinux or any linux without secure boot. I don't see a problem if you ask me. |
|
Hi @dawidpotocki Anyway, I had 7D45v19 installed on my system that is older and it has the same issue. You can see in the image below that I had to update my settings manually as well. Hope this helps you update the table with the right versions.
|
This change is not relevant.
Um, but that Secure Boot is doing nothing with the default settings and you can
It's a beta version, it's unlisted.
That's for DDR5 version.
You can see that you have firmware from 2022-09-02 and the one that I listed is |
|
MSI have made a statement on their subreddit (and nowhere else): |
|
Does anyone else interpret the MSI response as doubling down on their insecure defaults decision? It's only a matter of time before enterprising black hats start using BYOF (bring your own firmware) on MSI motherboards to bypass secure boot by resetting options to defaults. They're using the letter of a spec to bypass the spirit of the spec making secure boot truly useless for the vast majority of their customers (since very few will know or notice the change). If anyone really wanted to use an OS that doesn't support secure boot, they could have already just turned it the eff off. However, I'm not surprised by MSI's response based on previous experience with them. |
Tbh, have you expected anything else? They had few options:
It was either that or no statement. At the very least it looks like they are going to fix their defaults, if
They have made this change to bypass Windows 11 requirements of having Secure |
|
@dawidpotocki You might want to consider throwing that motherboard in the trash anyway, it will NEVER work properly for Secure Boot :> Not many people are aware of this (and even less care) but MSI motherboards that ship with this setting also ship with ME configured in Manufacturing Mode and no OEM key or manifest is present. This means that:
Can you fix it yourself? No. While you can exit Manufacturing Mode yourself to at least avoid someone else making changes to Boot Guard policy, this will effectively write down open-for-everyone config into PCH's OTP memory. Installing manifest would require signing it with MSI's key and such key also needs to have Intel's blessing. In general, trust of chain follows:
|
|
I know that it is a case for some MSI boards, but according to fwupdmgr, |
|
That's curious. If you are able to source CSME System Tools for v16+ you could try running |
|
Welp, tried v16 and told me that Raptor Lake is unsupported, only Alder Lake. |
|
You can see it with Fedora 37 and Fedora 38 Rawhide that the Intel Management Engine is located Manufacturing Mode. |
|
This is a different board and this info comes from fwupd. |
|
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 :) |
|
Btw turning those 3 into always deny result in msi b550 gaming wifi edge cannot boot at all. Can't even go to uefi |
|
@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. |
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. |
|
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? |
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 |
|
Well, I'm glad I asked. I was afraid it was too good to be true. Thank you for following up. |
|
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/ |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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.
The text was updated successfully, but these errors were encountered: