Update 1/22/23: Title updated as MSI intentionally changed this setting as per statement below.
Over 290 MSI motherboards are reportedly affected by an insecure default UEFI Secure Boot setting settings that allows any operating system image to run regardless of whether it has a wrong or missing signature.
This discovery comes from a Polish security researcher named Dawid Potocki, who claims that he did not receive a response despite his efforts to contact MSI and inform them about the issue.
The issue, according to Potocki, impacts many Intel and AMD-based MSI motherboards that use a recent firmware version, affecting even brand-new MSI motherboard models.
UEFI Secure Boot
Secure Boot is a security feature built into the firmware of UEFI motherboards that ensures only trusted (signed) software can execute during the boot process.
"When the PC starts, the firmware checks the signature of each piece of boot software, including UEFI firmware drivers (also known as Option ROMs), EFI applications, and the operating system," explains Microsoft in an article about Secure Boot.
"If the signatures are valid, the PC boots, and the firmware gives control to the operating system."
To validate the safety of boot loaders, OS kernels, and other essential system components, Secure Boot checks the PKI (public key infrastructure) that authenticates the software and determines its validity on every boot.
If the software is unsigned or its signature has changed, possibly because it was modified, the boot process will be stopped by Secure Boot to protect the data stored on the computer.
This security system is designed to prevent UEFI bootkits/rootkits (1, 2, 3) from launching on the computer and to warn users that their operating system has been tampered with after the vendor shipped the system.
Default MSI settings cause insecure boots
Potocki claims that MSI's firmware updates released between September 2021 and January 2022 changed a default Secure Boot setting on MSI motherboards so that the system will boot even if it detects security violations.
"I decided to setup Secure Boot on my new desktop with the help of sbctl. Unfortunately, I have found that my firmware was accepting every OS image I gave it, no matter if it was trusted or not," explains the researcher in his writeup.
"As I have later discovered on 2022-12-16, it wasn't just broken firmware; MSI had changed their Secure Boot defaults to allow booting on security violations(!!)."
This change was to mistakenly set the "Image Execution Policy" setting in the Firmware to "Always Execute" by default, allowing any image to boot the device as normal.
Source: dawidpotocki.com
As you can see from the image above, even though Secure Boot is enabled, it's 'Image Execution Policy' setting is set to 'Always Execute', allowing the system to boot even if there are security violations.
This effectively breaks the Secure Boot feature as untrusted images can still be used to boot the device
Potocki explains that users should set the Execution Policy to "Deny Execute" for "Removable Media" and "Fixed Media," which should only allow signed software to boot.
The researcher says MSI never documented the change, so he had to trace back the introduction of the insecure default using IFR (UEFI Internal Form Representation) to extract configuration options information.
Potocki then used this information to determine which MSI motherboards were impacted by the issue. A complete list of the over 290 motherboards and the firmware versions affected by this insecure setting is available on GitHub.
If you're using an MSI motherboard in that list, go over to BIOS settings and check that the "Image Execution Policy" is set to a safe option.
If you haven't upgraded your motherboard firmware since January 2022, the introduction of a bad default shouldn't be a reason to postpone it any further, as software updates contain important security fixes.
BleepingComputer has contacted MSI to request a comment on the above and whether they plan to change the default setting via a new update, but we are still waiting to receive a response.
Update 1/18 - BleepingComputer has received clarifications from Dawid Potocki about the vulnerable firmware versions for each MSI motherboard model and performed the required corrections on the article.
Update 1/20 - MSI is yet to respond to BleepingComputer's request for a comment, but the company posted the following statement on Reddit:
MSI implemented the Secure Boot mechanism in our motherboard products by following the design guidance defined by Microsoft and AMI before the launch of Windows 11.
We preemptively set Secure Boot as Enabled and "Always Execute" as the default setting to offer a user-friendly environment that allows multiple end-users flexibility to build their PC systems with thousands (or more) of components that included their built-in option ROM, including OS images, resulting in higher compatibility configurations.
For users who are highly concerned about security, they can still set “Image Execution Policy” as "Deny Execute" or other options manually to meet their security needs.
In response to the report of security concerns with the preset bios settings, MSI will be rolling out new BIOS files for our motherboards with ”Deny Execute” as the default setting for higher security levels. MSI will also keep a fully functional Secure Boot mechanism in the BIOS for end-users so that they can modify it according to their needs.
Comments
fromFirefoxToVivaldi - 1 year ago
If that's true, great for MSI as this seems like a way to keep compliance with ridiculous Windows requirements while not limiting users to secure boot BS when it comes to linux and bsd.
ibastavd - 1 year ago
Well I just changed the fixed media and removable media to always deny and my windows 11 PC won't boot with those two options enabled? Restored and it boots fine... wtf?
h_b_s - 1 year ago
@fromFirefoxtoVivaldi: You can turn off secure boot to begin with so that's not a concern. What is a concern is that it makes secure boot itself irrelevant with these default settings, and users were not properly informed of the changes even if they use secure boot - they expect it to work as intended which it now doesn't.
@ibastavd: The correct setting is "Deny Execute" not "Always Deny". I know it's counter intuitive but "Always Deny" sets the system to refuse to boot, or even properly POST if you set it on the option ROM, even if the signatures are valid. If people find themselves at a black screen and an unresponsive system, clear firmware options via the motherboard jumper and change the settings to "Deny Execute", and don't forget to restore the rest of your settings!
The truly scary part of this whole mess is how many other OEMs may be doing the same thing. This opens up a huge can of worms in at least one way: it's now theoretically possible to just overwrite the firmware on these boards with perfectly legitimate firmware packages from the OEM themselves (no need to force downgrades or figure out if MSI signs its firmware) to render secure boot useless without any other interactions because MSI firmware upgrades revert all options to default every time.
lonegull - 1 year ago
All Z790 motherboards do not all share the same BIOS version number and nothing even remotely similar to 7C02v3C. My Z790 motherboard wasn't available until October of 2022, so I fail to see how it is affected by a January BIOS update. I admittedly do not understand the details of this, but sounds rather dubious. I will wait for instructions from MSI before I start tinkering with Secure Boot settings.
h_b_s - 1 year ago
"All Z790 motherboards do not all share the same BIOS version number and nothing even remotely similar to 7C02v3C. My Z790 motherboard wasn't available until October of 2022, so I fail to see how it is affected by a January BIOS update. I admittedly do not understand the details of this, but sounds rather dubious. I will wait for instructions from MSI before I start tinkering with Secure Boot settings."
Misunderstood the part about this being a change in default settings did you? All motherboards from the same OEM tend to have the same basic firmware (provided by others as a generic package) with the same defaults across most, if not all, models. The changes eventually trickle down to supported boards, including newly released ones since it's largely a single shared code package that's only altered to change ACPI tables and the like.
If you actually followed the link to the Github discussion, you would find out whether or not your particular board was discovered to be affected. Also, MSI has ignored all attempts by the discoverer to contact them. You're likely to never receive any communication from MSI even if they eventually respond to Potocki. I doubt they will, MSI technical support is awful beyond RMAs. I know from experience, as I've tried to file bug reports against their firmware before and got very dismissive attitudes from their support team. Won't be buying them again.
dawids-throwaway - 1 year ago
This was because this article is incorrect. 7C02v3C is a version for B450 TOMAHAWK MAX.
I contacted the reporter to fix it but I'm getting no response from the guy…
EDIT: Got a response and it got fixed, unfortunately a bit too late.
Redix - 1 year ago
In my case, the MSI H510M-Pro Mainboard also has another problem. The Intel Managment Engine Manufactoring Mode is activated. You can see that with Fedora 37/38(Settings, privacy, device security).
h_b_s - 1 year ago
MSI has finally responded
https://www.reddit.com/r/MSI_Gaming/comments/10g9v3m/msi_statement_on_secure_boot/
I read it as doubling down on their decision with a brain dead reasoning that gives me a headache. People that want to use an OS that doesn't support secure boot signatures can already turn the option off. This reasoning uses the lettering of the spec to ignore the spirit of the spec. Now the vast majority of their customers will no longer have basic root kit and malware persistence protections and will never know they don't because Windows is going show secure boot is active, but it's neutered and ineffective which won't be shown to the user I've already looked, Windows does NOT detect if secure boot is on but bypassed.