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

+++
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.