MSI's (in)Secure Boot: Part 2
This is a continuation of "MSI's (in)Secure Boot". You might be a bit lost if you haven't read it.
On 2022-01-16 a lot of websites started writing articles about my "discovery" (I will cover this a bit later) and because of this, MSI responded on 2022-01-19 on their subreddit.
Their statement has been… a bit weird.
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.
Let's break it up a bit.
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.
That's false. They have not.
First, let's think about this sentence for a moment. Microsoft requires Secure Boot to be enabled with Windows 11. Why would Microsoft require it but at the same time be fine with it doing no verification?
While I'm not able to find any guidance from Microsoft that vendors have to do verification of binaries executed during boot stage (because I assume that it felt like something obvious to Microsoft), there is guidance about verification of Option ROMs and it is publicly available! If you forgot what an Option ROM is, it is basically a firmware that is loaded by a PCI-e expansion card, like a GPU.
This document talks about why you need to validate option ROMs and shows some techniques of doing it.
[…]
The default value (0x00) is
ALWAYS_EXECUTE, which does not properly perform verification of signed drivers in Option ROMs for add-in peripherals. This is not an ideal value for any system implementing UEFI Secure Boot functionality.
I guess MSI has not read Microsoft's guidance. Yes, I know that the date displayed on the website is after Windows 11 release, but this is the date on which the page got updated, not the release date. If we look at the guidance for Windows 8, we will find the same recommendations, but from 2014.
Now, what about AMI? Surely MSI isn't lying here. I bet AMI is fine with this… oh no, they aren't.
AMI also said these options are not recommended to be built into a MP [production] BIOS and only for develop stage, because this might violate MS's security policy.
MSI has decided to contact me after all the attention brought to this issue, so now I'm be able to share even more details, like this!
Weirdly enough, they have first told one of their forum administrators to ask me for my email address… which is very clearly visible on the top of my website. Because I was not checking their forums, at some point they have decided to get my email from my website and I have been in contact with their motherboard team since then.
Hope this email finds you well, and we apologize for the late response due to the Chinese New Year.
Fair enough, I guess? Still doesn't explain lack of contact from their US team that I tried contacting earlier that was very clearly working.
First of all, we do appreciate all the effort you've contributed to the research, and we understand your worries about PC security. After verifying the points you raised in the article and the questions on Reddit after we post the statement, we'd like to bring up our perspective and thought for positive discussions with you.
What's interesting about this is that they have read the questions I have asked like "Why wasn't this mentioned in the changelogs?" or "Can you provide an official list of the affected firmware?", but have decided to not answer them. I reasked them this and they ignored these questions, again.
When we reviewed the product characteristic of our motherboard and target audience in the consumer market, we found that's necessary to aggregate into a balanced solution more suitable for the real-world requirement without too much compromise.
[…]
We decided to set Secure Boot as Enabled and "Always Execute" as a default setting for offering a flexible environment that allows multiple end-user they can build up their PC system with thousands (or more) of components that included their built-in option ROM, including OS image, available in a higher compatibility configuration.
Not sure about what OSes MSI is talking about, as now even unsupported Windows 7 and many "mainstream" Linux distributions have Secure Boot support. Also, if your OS doesn't support Secure Boot, just disable it.
But what about other Linux distributions that don't have Secure Boot support?
GRUB, which is the most common bootloader for Linux distributions, expects shim to be available when Secure Boot is enabled, which is only available on distributions that support Secure Boot. Now, if shim isn't available and Secure Boot is enabled, then GRUB will complain and refuse to boot anything.
error: shim_lock protocol not found
error: you need to load kernel first
What about other bootloaders?
Well, do you really think that MSI cares about them? They already don't really care about Linux support. But yes, for example systemd-boot will boot just fine.
What about Option ROMs?
This is actually a somewhat valid concern as it could cause people to not be able to have video out from old GPUs. But at this point, I feel like your integrated graphics would have better performance than them.
Of course, for end-users who are in highly concern about security, they can still set it as "Deny Execute" or other options manually to meet their security needs, and we will clarify whether “Deny Execute” or other setting is better for Removable Media and Fixed Media.
Not sure what other setting would be better as this is the behaviour everyone would expect from Secure Boot being enabled.
We also noticed that setting "Option ROM" as Always Deny or Deny Execute might bring up display issues with user’s graphics card, so we still need to review the default settings further for Option ROM.
Here is a funny bit. MSI has noticed that doing "Always Deny" can cause issues, which just like the name implies, will always deny, even if it is correctly signed. Good job.
Now, because of the Chinese New Year, I had to be very patient and wait a bit over a week for them to answer questions I asked them via email.
But after the wait, I have learnt something… a bit depressing.
MSI's other security issues
We've started to lock ME FW on our MBs since Intel 700 series.
MSI hasn't disabled Intel ME manufacturing mode until very recently with the release of their Z790 and B760 Intel motherboards.
If you have no idea what Intel ME is, it's a subsystem in all modern Intel chipsets that runs even when the device is turned off and has full access to memory.
Manufacturing mode is not very well documented, but TL;DR is that it allows attackers to write whatever they want to the region where Intel ME resides on. For example they could write an older vulneralbe Intel ME version to the board and take advantage of INTEL-SA-00086 vulnerability to allow them to execute arbitrary code in Intel ME. This would give them full access to the computer, even when it's turned off.
We need to allow OS BIOS update because it is requested by our customers and system builders. Unfortunately, not all customers can use our M-FLASH feature.
Another fun thing, SPI locks are disabled on all MSI motherboards. This means that an attacker can modify firmware from the OS, if they have root access.
[…] our Intel 700 BIOS ROM files support Secure Flash so they cannot be modified or altered by tools. With Secure Flash support the BIOS ROM files are safer from malicious attempts.
Secure Flash enabled BIOS ROM files cannot be modified by tools, so it cannot be customized by general users. If the custom BIOS were built from other sources, it is not supported by Secure Flash and would be blocked by flash programmer.
Apparently MSI has introduced "Secure Flash" with their Z790 and B760 Intel boards (unsure about their AMD boards) which would prevent modifications of the firmware.
I assume they are talking about AMI's Secure Flash, which from the slides I have been able to find, has been a thing since at least 2013. It is an implementation of NIST SP 800-147 and if we are to believe what MSI has told me (yikes, that's hard), it isn't possible to flash unauthorised firmware even when using an external programmer.
MSI's Secure Boot solution
On 2023-02-07, MSI has sent me this email:
Here is the test BIOS E7E07IMS.A32T2 with the new Secure Boot settings design. It can be updated by the M-FLASH tool. In the new BIOS "Image Execution Policy" item is replaced by "Target OS" with two options:
- Non-UEFI OS (= Always Execute for all devices, default setting)
- Windows UEFI OS (= Deny Execute for all devices)
The new BIOS settings might not be same as your expectations, and please understand that we have been collecting user feedback and customer opinion on the Secure Boot settings and consider the suitable options for most users' need.
[…]
Feel free to let us know your opinion on this BIOS.
At this point, I have become fed up with MSI.
They are sending me this new firmware to test that has the same garbage insecure defaults, which was the main issue. Also they have replaced very flexible and somewhat understandable options, with options that are more vague than politicians, which is quite an achievement. They also know that I won't like their firmware at all, so why even bother asking me for my opinion?
First, what is a "Non-UEFI OS" target of Secure Boot? It makes no sense, you can't use a non-UEFI OS with Secure Boot as it's a feature of UEFI.
Second, "Windows UEFI OS"? Okay, so they know that their main target is Windows users and yet they don't want to set their settings for that OS? And what about the other OSes that MSI talked earlier? It's not like they don't work with this option, they work just fine, name is just misleading.
And what about their earlier promise of more secure defaults?
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 keep BIOS updating with proper default settings to optimize user experience.
Why keep your promises when you can just rename your settings to make it look like you did something?
I have replied to MSI and gave them my recommendation on how to improve on it, which included:
- defaulting to a fully-validating setting;
- renaming options to something less vague;
- having an option to set "Option ROM" to something else than "Always Execute" since they EXPLAINED TO ME 3 TIMES THAT I NEED TO UNDERSTAND THAT PC IS A VERY FLEXIBLE ENVIRONMENT AND HAS A LOT OF HARDWARE COMBINATIONS as if I forgot the previous 2 times and I obviously didn't know this myself;
- removing "Enroll all Factory Default keys" and "Delete all Secure Boot variables" from the main Secure Boot menu as it is already available in "Key Management" and can cause confusion. For example, selecting "Delete all Secure Boot variables" will show you a message that your board will be put in a "Setup Mode", but this won't happen if you don't turn off "Provision Factory Default keys" from "Key Management", which is enabled by default;
- allow to change the validation profile without having to change "Secure Boot Mode" to "Custom", in effort to make it more inviting for the user to change.
On 2023-02-21, MSI publicly released new beta firmware for their AMD AM5 boards which included this new option menu… with just changed names.
OneOf Prompt: "Secure Boot Preset", Help: "Set Hardware/OS Compatibility for some non-UEFI or non-compliant Hardware/OS with optimized functions, or to set Maximum Security for full validation of all components installed.", QuestionFlags: 0x10, QuestionId: 0xFB, VarStoreId: 0xF, VarOffset: 0x4, Flags: 0x10, Size: 8, Min: 0x0, Max: 0x5, Step: 0x0
Default DefaultId: 0x0 Value: 0
OneOfOption Option: "Hardware/OS Compatibility" Value: 0
OneOfOption Option: "Maximum Security" Value: 5
End
Because I don't have any AMD AM5 board, I had to look at the IFR data. As we can see, only the names got changed and that's it. They didn't change anything else. 0 equals to "Always Execute" and 5 equals to "Deny Execute" for "Option ROM", "Removable Media" and "Fixed Media" options.
It honestly feels like they are trying to keep compatibility with rootkits.
Thanks, MSI. Good job. I think it's pretty clear at this point that they won't fix it.
CVE request
As per given advice, I have requested a CVE ID for this issue on 2022-01-12, as "configuration vulnerabilities" are applicable for an ID.
Website for requesting a CVE ID sucks. The way they have made their form is mind boggling. MITRE wants you to fill the affected product and version, but the issue is that when you have more than one product affected, then you need to add them one by one. They have made the "Add" button work by sending your entire form in HTML to their servers and then sending back your entire HTML form with a new field. At some point, you have to wait over 10 seconds to get the modified form back.
After filling about 150 motherboards… the website started denying my requests.
I gave up and gave them a link to the GitHub issue with all the affected boards and explained to them that their server was declining my requests, so that they fill this themselves manually. I guess they assumed that no moron like me would try to add so many of them.
MITRE has finally looked over my request on 2022-02-23 and… declined it.
This request cannot receive a CVE ID assignment as it did not include a specific product name.
sighs, lazy bums.
Media coverage
Feel free to skip this section, it's just me complaining about the state of the "tech news reporting".
There have been a lot of sites that have covered this issue and a lot of them have caused frustration on my side, but I will not call out any names here.
Some website had made a mistake in their coverage. This is fine, mistakes happen!
But then some other website has decided to copy content from that website and have made the same mistakes and then most other websites decided to copy coverage of that second website.
I know that none of these websites, except the first website and maybe the second website, have read my blog post, because after the second website made the same mistakes, I have added a warning that clarifies the details and says that some websites have made such mistakes. It was hard to make these mistakes unless you didn't read the whole post, even before me adding this warning.
Contacting some of the websites has been a total pain in the ass, as not all of them had a way to contact the writer. One writer told me that my post has been "too long and analytical" and that it "passed multiple editors and nobody noticed the issues". Unfortunately edits don't really matter if it has been long after everyone read the articles, so my efforts were ultimately a waste of time.
At some point, one site decided to spread a bit of FUD and claimed that ASUS and Gigabyte boards might also be affected, but they aren't sure! WELL, HOW ABOUT YOU TEST IT YOURSELF? But no, nobody bothered and the news has spread.
It just shows how little most of the sites care about having their details straight, all they care about is clicks and ad revenue from them.
There were obviously few exceptions and these sites will be the ones that I will visit more often. Big thank you to everyone that didn't just lazily copy-paste from someone else. Seems like a very low bar, but yet here we are!
Conclusion
This whole situation has been pretty overwhelming to me.
From MSI doing MSI stuff, MITRE being lazy, news sites quickly jumping in for clicks to overall having personally a lot of attention.
I have tried my best, but I can't solve issues introduced by some multi-million company when said company doesn't feel like doing it.
I… give up, I did all that I could, but it was worth a shot. They have not talked with me for over a week and I do not feel like continuing it, it's a waste of my time.
Will I buy more stuff from MSI or recommend their products to others? Unless something changes internally in the company, hell no.