New post "MSI's (in)Secure Boot: Part 2"HEADmaster

5 files changed, 834 insertions, 0 deletions

diff --git a/content/blog/msi-insecure-boot-part-2.en.md b/content/blog/msi-insecure-boot-part-2.en.md
new file mode 100644
index 0000000..870b54a
--- /dev/null
+++ b/content/blog/msi-insecure-boot-part-2.en.md
@@ -0,0 +1,401 @@
++++
+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.
diff --git a/content/blog/msi-insecure-boot-part-2.pl.md b/content/blog/msi-insecure-boot-part-2.pl.md
new file mode 100644
index 0000000..934084d
--- /dev/null
+++ b/content/blog/msi-insecure-boot-part-2.pl.md
@@ -0,0 +1,425 @@
++++
+title = "(in)Secure Boot MSI: Część 2"
+slug = "msi-insecure-boot-czesc-2"
+date = "2023-02-26"
++++
+
+***To jest kontynuacja
+["(in)Secure Boot MSI"](/pl/2023/01/13/msi-insecure-boot/).
+Możesz być trochę zagubiony, jeśli nie czytałeś tego.***
+
+W dniu 2022-01-16 sporo stron zaczęło pisać artykuły o moim "odkryciu"
+(omówię to nieco później) i z tego powodu,
+[MSI odpowiedziało](https://old.reddit.com/r/MSI_Gaming/comments/10g9v3m/msi_statement_on_secure_boot/)
+w dniu 2022-01-19 na swoim subredditcie.
+
+Ich wypowiedź była… trochę dziwna.
+
+> MSI zaimplementowało mechanizm Secure Boot w naszych płytach głównych,
+> stosując się do wytycznych zdefiniowanych przez Microsoft i AMI przed
+> wydaniem Windowsa 11. Wstępnie ustawiliśmy Secure Boot jako Włączone i
+> "Deny Execute" (zabraniaj uruchamiania) jako ustawienie domyślne, aby
+> zaoferować przyjazne dla użytkownika środowisko, które pozwala wielu
+> użytkownikom na elastyczność w budowaniu swoich systemów komputerowych
+> z tysiącami (lub więcej) komponentów, które zawierały wbudowane Option
+> ROMy, w tym obrazy OS, co skutkuje wyższą konfiguracją
+> kompatybilności. Użytkownicy, którzy przywiązują dużą wagę do
+> bezpieczeństwa, mogą nadal ustawić "Image Execution Policy" jako "Deny
+> Execute" (zabraniaj uruchamiania) lub inne opcje, aby spełnić swoje
+> potrzeby w zakresie bezpieczeństwa.
+>
+> W odpowiedzi na doniesienia o problemach bezpieczeństwa w ustawieniach
+> biosu, MSI wprowadzi nowe pliki BIOS dla naszych płyt głównych z "Deny
+> Execute" jako domyślnym ustawieniem dla wyższych poziomów
+> bezpieczeństwa. MSI zachowa także w pełni funkcjonalny mechanizm
+> Secure Boot w BIOS-ie dla użytkowników końcowych, aby mogli go
+> zmodyfikować zgodnie ze swoimi potrzebami.
+
+Rozłóżmy to trochę na części.
+
+> MSI zaimplementowało mechanizm Secure Boot w naszych płytach głównych,
+> stosując się do wytycznych zdefiniowanych przez Microsoft i AMI przed
+> wydaniem Windowsa 11.
+
+To nieprawda. Nie zrobili tego.
+
+Po pierwsze, zastanówmy się przez chwilę nad tym zdaniem. Microsoft
+wymaga, aby Secure Boot był włączony w Windowsie 11. Dlaczego Microsoft
+wymagałby tego ale jednocześnie nie miał nic przeciwko temu, aby nie
+przeprowadzał weryfikacji?
+
+Chociaż nie jestem w stanie znaleźć żadnych wytycznych od Microsoftu, że
+dostawcy muszą dokonywać weryfikacji binarek uruchamianych podczas
+bootowania (ponieważ zakładam, że jest to coś oczywistego dla
+Microsoftu), to istnieją wytyczne dotyczące weryfikacji Option ROMów i
+są one publicznie dostępne! Jeśli zapomniałeś czym jest Option ROM, to
+jest to po prostu firmware, który jest ładowany przez karty PCI-e, jak
+na przykład GPU.
+
+https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/uefi-validation-option-rom-validation-guidance
+
+> Ten dokument mówi o tym, dlaczego należy sprawdzać Option ROMy i
+> pokazuje kilka technik, jak to zrobić.
+>
+> Domyślną wartością (0x00) jest `ALWAYS_EXECUTE`, która nie wykonuje
+> weryfikacji podpisanych sterowników w Option ROM dla urządzeń
+> peryferyjnych typu add-in. To nie jest idealna wartość dla żadnego
+> systemu implementującego UEFI Secure Boot.
+
+Chyba MSI nie przeczytało wytycznych Microsoftu. Tak, wiem, że data
+wyświetlana na stronie jest sporo po premierze Windowsa 11, ale jest to
+data, w której strona została zaktualizowana, a nie data wydania. Jeśli
+sprawdzimy
+[wytyczne dla Windowsa 8](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-8.1-and-8/dn747882(v=win.10))
+to znajdziemy te same zalecenia, ale z 2014 roku.
+
+A co z AMI? Z pewnością MSI tu nie kłamie. Założę się, że AMI jest w
+porządku z tym… oh nie, nie jest.
+
+> AMI powiedziało również, że te opcje nie są zalecane do wbudowania w
+> MP [produkcyjny] BIOS a tylko do etapu programowania, ponieważ może to
+> naruszać politykę bezpieczeństwa MS.
+
+MSI postanowiło skontaktować się ze mną po tym, jak cała uwaga została
+zwrócona na tę sprawę więc jestem teraz w stanie podzielić się jeszcze
+większą ilością szczegółów!
+
+O dziwo, najpierw kazali jednemu ze swoich administratorów forum
+poprosić mnie o mój adres email… który jest bardzo wyraźnie widoczny
+na górze mojej strony. Ponieważ nie sprawdzałem ich forum, w pewnym
+momencie postanowili wsiąść mój email z mojej strony i od tego czasu
+jestem w kontakcie z ich zespołem od płyt głównych.
+
+> Mamy nadzieję, że ten email dotrzę do Ciebie i przepraszamy za późną
+> odpowiedź z powodu Chińskiego Nowego Roku.
+
+No ok, ale nadal nie tłumaczy to braku kontaktu ich zespółu z USA, z
+którym próbowałem się skontaktować wcześniej, a który bardzo wyraźnie
+pracował.
+
+> Po pierwsze, doceniamy cały wysiłek, jaki włożyłeś w research i
+> rozumiemy twoje obawy o bezpieczeństwo. Po sprawdzeniu punktów, które
+> poruszyłeś w artykule i pytań na Redditcie po tym, jak zamieściliśmy
+> oświadczenie, chcielibyśmy przedstawić naszą perspektywę i myśl do
+> pozytywnej dyskusji z Tobą.
+
+Interesujące jest to, że przeczytali moje pytania, które zadałem, takie
+jak "Dlaczego nie było to wspomniane w liście zmian?" lub "Czy możecie
+dostarczyć oficjalną listę firmware'u z tym problemem?", ale zdecydowali
+się nie odpowiadzieć na nie. Zadałem im te pytania ponownie, a oni
+zignorowali je, ponownie.
+
+> Kiedy przejrzeliśmy charakterystykę produktu naszych płyt głównych i
+> docelowych odbiorców na rynku konsumenckim, stwierdziliśmy, że
+> konieczne jest zagregowanie w zrównoważone rozwiązanie bardziej
+> odpowiednie dla rzeczywistych wymagań bez zbytniego kompromisu.
+>
+> […]
+>
+> Zdecydowaliśmy się ustawić Secure Boot jako włączone i "Always
+> Execute" (zawsze uruchamiaj) jako ustawienie domyślne, aby zaoferować
+> elastyczne środowisko, które pozwala wielu użytkownikom zbudować swój
+> komputer z tysiącami (lub więcej) komponentów, które zawierały
+> wbudowane Option ROMy, w tym obraz systemu operacyjnego, dostępny w
+> konfiguracji o wyższej kompatybilności.
+
+Nie jestem pewien o jakich systemach MSI mówi, ponieważ teraz nawet
+niewspierany Windows 7 i wiele "mainstreamowych" dystrybucji Linuxa
+działa z Secure Boot. Ponadto, jeśli twój system operacyjny nie
+obsługuje Secure Boot, po prostu go wyłącz.
+
+*Ale co z innymi dystrybucjami Linuxa, które nie mają wsparcia Secure
+Boot?*
+
+GRUB, który jest najbardziej popularnym bootloaderem dla dystrybucji
+Linuxowych, oczekuje, że shim będzie dostępny, gdy Secure Boot jest
+włączony, co jest dostępne tylko w dystrybucjach, które wspierają Secure
+Boot. Jeśli shim nie jest dostępny, a Secure Boot jest włączony, GRUB
+tupnie nóżką i odmówi uruchomienia systemu.
+
+```
+error: shim_lock protocol not found
+error: you need to load kernel first
+```
+
+*Co z innymi bootloaderami?*
+
+Cóż, czy naprawdę myślisz, że MSI na nich zależy? Im samym nie zależy na
+wsparciu dla Linuxa. Ale tak, na przykład systemd-boot będzie uruchamiał
+systemy bez problemu.
+
+*A co z Option ROMami?*
+
+Jest to w zasadzie wmiare uzasadniona obawa, ponieważ może to
+spowodować, że ludzie nie będą w stanie uzyskać obrazu ze starszych kart
+graficznych. Ale wydaje mi się, że teraz twoja zintegrowana grafika
+będzie miała lepszą wydajność niż te karty.
+
+> Oczywiście, użytkownicy, którzy są bardzo zaniepokojeni
+> bezpieczeństwem, mogą nadal zmienić na "Deny Execute" (zabraniaj
+> uruchamiania) lub inne opcje, aby spełnić swoje potrzeby
+> bezpieczeństwa, a my wyjaśnimy, czy "Deny Execute" (zabraniaj
+> uruchamiania) lub inne ustawienie jest lepsze dla "Removable Media"
+> (nośników wymienialnych) i "Fixed Media" (wewnętrznych dysków).
+
+Nie jestem pewien jakie inne ustawienie byłoby lepsze, ponieważ jest to
+zachowanie, którego każdy oczekiwałby po Secure Boot.
+
+> Zauważyliśmy również, że ustawienie "Option ROM" jako Always Deny
+> (zawsze zabraniaj uruchamiania) lub Deny Execute (zabraniaj
+> uruchamiania) może powodować problemy z wyświetlaniem obrazu na
+> kartach graficznych użytkowników, więc musimy jeszcze przemyśleć
+> ustawienia domyślne dla Option ROM.
+
+A to jest trochę zabawny fragment. MSI zauważyło, że ustawienie "Always
+Deny" (zawsze zabraniaj uruchamiania) może powodować problemy, co tak
+jak nazwa wskazuje, zawsze będzie odmawiać, nawet jeśli jest poprawnie
+podpisane przez zaufany klucz. Dobra robota, MSI.
+
+Ze względu na Chiński Nowy Rok, musiałem być bardzo cierpliwy i czekać
+nieco ponad tydzień, aż odpowiedzą na moje pytania, które zadałem im
+mailowo.
+
+Ale po tym czekaniu dowiedziałem się czegoś… przygnębiającego.
+
+## Inne problemy bezpieczeństwem MSI
+
+> Od serii Intel 700 zaczęliśmy blokować ME FW na naszych MB.
+
+MSI nie wyłączyło trybu produkcyjnego Intel ME aż do niedawna, kiedy
+wydali swoje Intelowskie płyty główne Z790 i B760.
+
+Jeśli nie masz pojęcia, czym jest Intel ME, to jest to podsystem we
+wszystkich nowoczesnych chipsetach Intela, który działa nawet wtedy, gdy
+urządzenie jest wyłączone i dodatkowo ma on pełny dostęp do pamięci.
+
+Tryb produkcyjny nie jest zbyt dobrze udokumentowany, ale TL;DR jest
+taki, że pozwala atakującym na zapisanie czegokolwiek w regionie, w
+którym siedzi firmware Intel ME. Na przykład mogliby zapisać na płycie
+starszą wersję Intel ME i wykorzystać lukę
+[INTEL-SA-00086](https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00086.html)
+pozwalającą na wykonanie dowolnego kodu w Intel ME. To dałoby im pełny
+dostęp do komputera, nawet gdy jest wyłączony.
+
+> Musimy zezwolić na aktualizację BIOSu przez system, ponieważ jest to
+> wymagane przez naszych klientów i producentów systemów. Niestety, nie
+> wszyscy klienci mogą korzystać z naszej funkcji M-FLASH.
+
+Kolejna fajna sprawa, blokady SPI są wyłączone na wszystkich płytach
+głównych MSI. Oznacza to, że atakujący może modyfikować firmware z
+poziomu systemu operacyjnego, jeśli ma dostęp do roota.
+
+> […] nasze pliki BIOS ROM Intel 700 wspierają Secure Flash, więc nie
+> mogą być modyfikowane lub zmieniane przez narzędzia. Dzięki wsparciu
+> Secure Flash pliki BIOS ROM są bezpieczniejsze od złośliwych prób
+> modyfikacji.
+>
+> Pliki BIOS ROM z włączonym Secure Flash nie mogą być modyfikowane
+> przez narzędzia, więc nie mogą być modyfikowane przez zwykłych
+> użytkowników. Jeśli BIOS został zbudowany z innych źródeł, nie jest
+> obsługiwany przez Secure Flash i zostanie zablokowany przez
+> programator.
+
+Podobno MSI wprowadziło "Secure Flash" w swoich płytach Z790 i B760
+Intela (nie jestem pewien co do płyt AMD), co uniemożliwiłoby
+modyfikację firmware'u.
+
+Zakładam, że mówią o Secure Flash od AMI, które ze slajdów, które udało
+mi się znaleźć, istnieje od co najmniej 2013 roku. Jest to implementacja
+[NIST SP 800-147](https://csrc.nist.gov/publications/detail/sp/800-147/final)
+i jeśli mamy wierzyć temu, co powiedziało mi MSI (trochę ciężko), nie
+jest możliwe flashowanie nieautoryzowanego firmware'u nawet przy użyciu
+zewnętrznego programatora.
+
+## Rozwiązanie Secure Boot MSI
+
+W dniu 2023-02-07 MSI przysłało mi tego maila:
+
+> Oto testowy BIOS E7E07IMS.A32T2 z nowym ustawieniem Secure Boot. Można
+> go zaktualizować za pomocą narzędzia M-FLASH.
+> W nowym BIOSie pozycja "Image Execution Policy" została zastąpiona
+> przez "Target OS" (system docelowy) z dwoma opcjami:
+>
+> 1. Non-UEFI OS         (= Always Execute (zawsze uruchamiaj) dla
+>    wszystkich urządzeń, ustawienie domyślne))
+> 2. Windows UEFI OS (= Deny Execute (zabraniaj uruchamiania) dla
+>    wszystkich urządzeń)
+>
+> Nowe ustawienia BIOSu mogą nie odpowiadać Twoim oczekiwaniom i proszę
+> zrozum że zbieraliśmy opinie użytkowników i klientów na temat ustawień
+> Secure Boot i rozważyliśmy odpowiednie opcje dla większości
+> użytkowników.
+>
+> […]
+>
+> Zapraszamy do podzielenia się z nami swoją opinią na temat tego BIOSu.
+
+W tym momencie miałem już dość MSI.
+
+Wysyłają mi ten nowy firmware do przetestowania, który ma te same
+badziewne domyślne ustawienia, co było głównym problemem. Ponadto
+zastąpili bardzo elastyczne i bardziej zrozumiałe opcje, opcjami, które
+są bardziej mętne niż politycy, co jest sporym osiągnięciem. Wiedzą też,
+że nie spodoba mi się ich ten firmware, więc po co w ogóle pytać mnie o
+zdanie?
+
+Po pierwsze, co to jest za system docelowy Secure Boot który nie
+korzysta z UEFI? To nie ma sensu, nie można korzystać z systemu nie
+wspierającego UEFI z Secure Boot, ponieważ jest to funkcja UEFI.
+
+Po drugie, "Windows UEFI OS"? No dobra, czyli wiedzą, że ich głównym
+targetem są użytkownicy Windowsa, a mimo to nie chcą ustawić swoich
+ustawień pod ten system? A co z innymi systemami, o których MSI mówiło
+wcześniej? To nie jest tak, że one nie działają z tą opcją, działają
+bez problemu, nazwa jest po prostu myląca.
+
+A co z ich wcześniejszą obietnicą bezpieczniejszych domyślnych ustawień?
+
+> W odpowiedzi na doniesienia o problemach bezpieczeństwa w ustawieniach
+> biosu, MSI wprowadzi nowe pliki BIOS dla naszych płyt głównych z "Deny
+> Execute" jako domyślnym ustawieniem dla wyższych poziomów
+> bezpieczeństwa.
+
+> MSI będzie aktualizować BIOS z odpowiednimi ustawieniami domyślnymi,
+> aby zoptymalizować doświadczenia użytkownika.
+
+Po co dotrzymywać obietnic, skoro można po prostu zmienić nazwę
+ustawień, aby wyglądało na to, że coś zrobiłeś?
+
+Odpowiedziałem MSI i dałem im moją rekomendację, jak to poprawić, która
+obejmowała:
+
+- Domyślnie ustawienia które w pełni sprawdzają proces bootowania;
+- Zmiana nazwy opcji na coś bardziej zrozumiałego;
+- Możliwość ustawienia opcji "Option ROM" na coś innego niż "Deny
+  Execute" (zabraniaj uruchamiania), ponieważ TŁUMACZYLI MI 3 RAZY, ŻE
+  MUSZĘ ZROZUMIEĆ, ŻE PC JEST BARDZO ELASTYCZNYM ŚRODOWISKIEM I MA
+  BARDZO DUŻO KOMBINACJI SPRZĘTU tak jakbym zapomniał o poprzednich 2
+  tłumaczeniach i oczywiście sam bym tego nie wiedział;
+- Usunięcie opcji "Enroll all Factory Default keys" (wgraj wszystkie
+  fabryczne klucze) i "Delete all Secure Boot variables" (usuń wszystkie
+  zmienne Secure Boot) z głównego menu Secure Boot, ponieważ są one już
+  dostępne w "Key Management" (zarządzanie kluczami) i mogą spowodować
+  zdziwienie wielu osób. Na przykład, wybierając "Delete all Secure Boot
+  variables" (usuń wszystkie zmienne Secure Boot) spowoduje wyświetlenie
+  komunikatu, że Twoja płyta płyta zostanie przełączona w "Setup Mode",
+  ale to się nie stanie, jeśli nie wyłączysz opcji "Provision Factory
+  Default keys" (załaduj klucze fabryczne) w "Key Management", która
+  jest domyślnie włączona;
+- Umożliwienie zmiany profilu walidacji bez konieczności zmiany "Secure
+  Boot Mode" (tryb Secure Boot) na "Custom" (niestandardowy), aby
+  uczynić go bardziej przyjaznym do zmiany dla użytkownika.
+
+W dniu 2023-02-21, MSI publicznie wydało nowe beta firmware dla swoich
+płyt AMD AM5 które zawierało te nowe menu… tylko ze zmienionymi nazwami.
+
+```
+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
+```
+
+Ponieważ nie mam żadnej płyty AMD AM5, musiałem spojrzeć na dane IFR.
+Jak widać, zmieniły się tylko nazwy i tyle. Nic więcej nie zmienili. 0
+oznacza "Always Execute" (zawsze uruchamiaj), a 5 oznacza "Deny Execute"
+(zabraniaj uruchamiania) dla opcji "Option ROM", "Removable Media"
+(nośniki wymienne) i "Fixed Media" (wewnętrzne dyski).
+
+Szczerze mówiąc mam wrażenie, że próbują zachować kompatybilność z
+rootkitami.
+
+Dzięki MSI. Dobra robota. Myślę, że to dosyć jasne w tym momencie, że
+oni tego nie naprawią.
+
+## Wniosek o CVE
+
+Tak jak mnie poproszono, poprosiłem o ID CVE dla tego problemu w dniu
+2022-01-12, ponieważ "luki w konfiguracji" mogą dostać takowe ID.
+
+Strona do składania wniosków o CVE ID jest okropna. Sposób w jaki
+stworzyli swój formularz, jest nie do pomyślenia. MITRE chce, abyś
+wypełnił im nazwę dotkniętego produktu i wersję, ale problem polega na
+tym, że gdy masz więcej niż jeden produkt, musisz dodawać je jeden po
+drugim. Przycisk "Dodaj" działa tak że wysyła twój cały formularz w HTML
+do ich serwerów, a następnie wysyła z powrotem cały formularz HTML z
+nowym polem. W pewnym momencie musisz czekać ponad 10 sekund, aby
+otrzymać zmodyfikowany formularz z powrotem. Po wypełnieniu około 150
+płyt głównych… strona zaczęła odrzucać moje żadania HTTP.
+
+![Screenshot żądania HTTP](/img/blog/msi-insecure-boot-part-2/cve0.webp)
+
+Poddałem się i dałem im link do wydania GitHub ze wszystkimi dotkniętymi
+tablicami i wyjaśniłem im, że ich serwer odrzuca moje żądania, aby sami
+wypełnili to ręcznie. Domyślam się, że myśleli, że żaden kretyn jak ja
+nie będzie próbował dodać tak wielu produktów.
+
+MITRE w końcu przejrzało mój wniosek dniu 2022-02-23 i… odrzuciło go.
+
+> To zgłoszenie nie może otrzymać ID CVE, ponieważ nie zawierało
+> konkretnej nazwy produktu.
+
+*wzdycha*, leniwe gnoje.
+
+## Przekaz medialny
+
+Nie krępuj się pominąć tej sekcji, ja tu tylko będę narzekał na stan
+raportowania wiadomości technologicznych.
+
+Było wiele stron, które opisały ten problem i wiele z nich spowodowało
+u mnię frustrację, ale nie będę tutaj przywoływał żadnych nazw.
+
+Niektóre strony internetowe pomyliły się w swojej relacji. To jest okej,
+błędy się zdarzają!
+
+Ale potem jakaś inna strona zdecydowała się skopiować treść z tej strony
+i popełniła te same błędy, a potem większość innych stron zdecydowała
+się skopiować informacje tej drugiej strony.
+
+Wiem, że żadna z tych stron, poza pierwszą stroną i *może* drugą stroną,
+nie przeczytała mojego wpisu na blogu, ponieważ po tym, jak druga strona
+popełniła te same błędy, dodałem ostrzeżenie, które wyjaśnia szczegóły i
+mówi, że niektóre strony internetowe popełniły takowe błędy. Trudno było
+popełnić te błędy, nawet przed moim dodaniem tego ostrzeżenia, chyba że
+nie przeczytałeś całego postu.
+
+Próba kontaktu z niektórymi stronami internetowymi była strasznie
+frustrująca, ponieważ nie wszystkie z nich miały sposób na
+skontaktowanie się z reporterem. Jeden powiedział mi, że mój post był
+"zbyt długi i analityczny" i że "przeszedł przez wielu redaktorów i nikt
+nie zauważył problemów". Niestety edycje nie mają znaczenia, jeśli
+zostały wprowadzone długo po tym, jak wszyscy przeczytali te artykuły,
+więc moje wysiłki były ostatecznie stratą czasu.
+
+W pewnym momencie jedna ze stron postanowiła rozprowadzić trochę kłamstw
+i stwierdziła, że płyty ASUS i Gigabyte również mogą być dotknięte tym
+problemem, ale nie są pewni! NO TO MOŻE SAMI TO PRZETESTUJECIE? Ale nie,
+nikomu się tego nie chciało i wieści się rozeszły.
+
+To tylko pokazuje jak słabo większość stron dba o jakość swoich
+informacji, jedyne co ich obchodzi to kliknięcia i przychody z reklam.
+
+Oczywiście było kilka wyjątków i te strony będą tymi, które będę
+odwiedzał o wiele częściej. Wielkie podziękowania dla każdego, kto nie
+skopiował od kogoś innego. Jest to dosyć niska poprzeczka, no ale cóż
+poradzimy.
+
+## Konkluzja
+
+Cała ta sytuacja była dla mnie dość przytłaczająca.
+
+Od MSI robiącego jakieś głupie rzeczy, MITRE bedące leniami, stron
+piszących na odwal dla szybkich kliknięć do ogólnie posiadania dużo
+uwagi na sobie.
+
+Starałem się jak mogłem, ale nie mogę naprawić problemów stworzonych
+przez jakąś wielomilionową firmę, kiedy ta firma nie ma ochoty tego
+naprawić.
+
+Ja… się poddaję, zrobiłem wszystko co mogłem, ale warto było spróbować.
+MSI nie komunikuje ze mną od ponad tygodnia i nie mam ochoty tego
+kontynuować, to strata mojego czasu.
+
+Czy kupię więcej rzeczy od MSI lub polecę ich produkty innym? O ile coś
+się nie zmieni wewnętrznie w firmie, nie.
diff --git a/content/blog/msi-insecure-boot.en.md b/content/blog/msi-insecure-boot.en.md
index 302b1c2..6b4ca76 100644
--- a/content/blog/msi-insecure-boot.en.md
+++ b/content/blog/msi-insecure-boot.en.md
@@ -249,3 +249,8 @@ What's the difference between these 3 boards:
 Heatsink and PCB colours! They are the same board and share the same
 firmware! But hey, the red and white one is only for gamers but black is
 only suitable for "professionals".
+
+---
+
+**There is a continuation available of this post,
+["MSI's (in)Secure Boot: Part 2"](/en/2023/02/26/msi-insecure-boot-part-2/).**
diff --git a/content/blog/msi-insecure-boot.pl.md b/content/blog/msi-insecure-boot.pl.md
index d5d1a61..0ddc1a2 100644
--- a/content/blog/msi-insecure-boot.pl.md
+++ b/content/blog/msi-insecure-boot.pl.md
@@ -258,3 +258,6 @@ Jaka jest różnica między tymi 3 płytami:
 Kolor heatsinków i PCB! Są to te same płyty i mają ten sam firmware! Ale
 hej, czerwony i biały jest tylko dla graczy, ale czarny jest tylko dla
 "profesjonalistów".
+
+**Dostępna jest kontynuacja tego postu,
+["(in)Secure Boot MSI: Część 2"](/pl/2023/02/26/msi-insecure-boot-czesc-2/).**
diff --git a/static/img/blog/msi-insecure-boot-part-2/cve0.webp b/static/img/blog/msi-insecure-boot-part-2/cve0.webp
new file mode 100644
index 0000000..a3b2dee
--- /dev/null
+++ b/static/img/blog/msi-insecure-boot-part-2/cve0.webp