path: root/content/blog/msi-insecure-boot-part-2.en.md

+++
title = "MSI's (in)Secure Boot: Part 2"
date = "2023-02-26"
+++

***This is a continuation of
["MSI's (in)Secure Boot"](/en/2023/01/13/msi-insecure-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](https://old.reddit.com/r/MSI_Gaming/comments/10g9v3m/msi_statement_on_secure_boot/)
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.

https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/uefi-validation-option-rom-validation-guidance

> 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](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-8.1-and-8/dn747882(v=win.10)),
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](https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00086.html)
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](https://csrc.nist.gov/publications/detail/sp/800-147/final)
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:
>
> 1. Non-UEFI OS         (= Always Execute for all devices, default setting)
> 2. 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.

![Screenshot of a HTTP request](/img/blog/msi-insecure-boot-part-2/cve0.webp)

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.