(in)Secure Boot MSI

opublikowane 2023-01-13 (UTC), zaktualizowane 2023-01-20 (UTC)

Chyba wreszcie znalazłem powód, aby napisać swój pierwszy post na blogu.

Zanim zaczniemy, może szybko wyjaśnię czym jest Secure Boot. Jest to funkcja bezpieczeństwa, która pozwala naszemu komputerowi odmówić uruchomienia systemów operacyjnych, które nie zostały podpisane kluczem, któremu firmware ufa.

W dniu 2022-12-11, postanowiłem skonfigurować Secure Boot na moim PCecie z pomocą sbctl. Niestety okazało się, że mój firmware… akceptował każdy system operacyjny jaki mu dałem, nie ważne czy był podpisany przez zaufane przez firmware klucze czy nie. To nie był pierwszy raz, kiedy self-signowałem Secure Boot, nie robiłem tego źle, coś było nie tak.

Jak później odkryłem w dniu 2022-12-16, to nie był tylko zepsuty firmware, MSI zmieniło swoje domyślne ustawienia Secure Boot, aby umożliwić bootowanie na naruszeniach Secure Boot(!!).

Można to zmienić przechodząc do miejsca, w którym znajdują się ustawienia dla Secure Boot na Twojej płycie głównej. W moim przypadku jest to w zakładce Security\Secure Boot. Z tego miejsca możemy zobaczyć menu o nazwie "Image Execution Policy" które jest tego winowajcą.

Screenshot Firmware'u 0

Po wejściu w menu widzimy rozczarowujące ustawienia domyślne. Secure Boot nie przeprowadza żadnej weryfikacji. Jest on bezużyteczny. Jest tam tylko po to, aby spełnić wymagania Windows 11. System nie ma pojęcia, że Secure Boot nic nie robi, wie tylko, że jest "włączony".

Screenshot Firmware'u 1

Aby zmienić ustawienia na coś bardziej sensownego, musimy zmienić "Always Execute" (zawsze uruchamiaj) na "Deny Execute" (zabraniaj uruchamiania) dla "Removable Media" (nośniki wymienne) i "Fixed Media" (wenętrzne dyski). Co zabawne, opcje "Allow Execute" (zezwól uruchamianie) i "Query User" (zapytaj użytkownika) naruszają specyfikację UEFI, chociaż nie jestem do końca pewien, jaka jest różnica między "Allow Execute" (zezwalaj uruchamianie), a "Always Execute" (zawsze uruchamiaj).

Możemy również zmienić "Option ROM", o którym więcej możecie przeczytać więcej tutaj:

Screenshot Firmware'u 2

Sprawa zamknięta, można się rozejść, nie?

Cóż, nie do końca. Musiałem się dowiedzieć, czy problem ten dotyczy tylko moją płytę główną czy też inne modele, a może nawet innych producentów. A także musimy to udokumentować, nawet jeśli ja o tym wiem, prawdopodobnie jest wiele osób ludzi, którzy nie wiedzą o tym problemie.

Poprosiłem 2 użytkowników B450 TOMAHAWK MAX (dzięki Sage Hane i Daniel Nathan Gray) o sprawdzenie swojego firmware'u i co? Okazało się, że również tam jest ta opcja. Udało nam się ustalić, że wersja 7C02v3C z 2022-01-18 wprowadza ten problem.

EDIT: Zauważyłem, że niektóre strony podały błędne informacje na temat tego problemu, ponieważ nie przeczytały w pełni mojego artykułu. Ta wersja firmware dotyczy tylko B450 TOMAHAWK MAX, inne płyty główne mają inne wersje. 7C02 w tej wersji jest nazwą kodową dla B450 TOMAHAWK MAX. Więcej informacji jest dostępnych poniżej.

Czy jest to wspomniane w changelogu? Hah, nie.

Screenshot Firmware'u 3

Otrzymałem również informację od użytkownika B550-A PRO (CEC) (dzięki Joseph Richey), że mają ten problem od 7C56vH1 (2021-12-20) w zwyż.

Chociaż byłem w stanie ekstrapolować te informacje, aby zgadnąć, które wersje dla innych płyt wprowadziły ten problem, to nie jest to wystarczające. Musimy sięgnąć głębiej.

Próbowałem wydobyć pewne informacje z plików firmware'u MSI ale bezskutecznie. Próbowałem użyć binwalk, UEFITool i innych, ale nie znalazłem tego, co chciałem. Aż pewnego dnia dowiedziałem się, że UEFI ma rzecz zwaną "UEFI Internal Form Representation" lub w skrócie "IFR". Jest to sposób na opisanie opcji konfiguracyjnych firmware. To jest dokładnie to, czego muszę szukać! No i co teraz zrobimy z tą wiedzą?

Gdy już wyodrębnimy pliki z firmware za pomocą UEFIExtract z UEFITool, możemy znaleźć plik o nazwie plik o nazwie Section_PE32_image_899407D7-99FE-43D8-9A21-79EC328CAC21_Setup_body.bin. Zawiera on większość elementów GUI UEFI i wydaje się być dostępny na wszystkich firmware'ach od wszystkich dużych producentów płyt głównych, chociaż ASUS postanowił usunąć "Setup" z nazwy z jakiegoś powodu, ale może ma to związek z coś wspólnego z UEFIExtract, nie jestem pewien.

EDIT (dzięki Nikolaj Schlej): "Setup" pochodzi z sekcji User Interface pliku FFS z GUID 899407D7-99FE-43D8-9A21-79EC328CAC21. Niektórzy producenci nie mają sekcji UI, więc nie będzie "Setup" w jego nazwie, ale większość z nich nie zmienia domyślnego GUID, który AMI wybrał dla ich firmware.

Teraz, gdy mamy już ten plik, musimy wyodrębnić z niego dane IFR. możemy użyć IFRExtractor RS. Co zabawne, jest on tworzony przez tych samych ludzi co UEFITool. Dzięki koledzy za waszą ciężką pracę, inaczej musiałbym to zrobić sam ;p.

Teraz dzięki wyodrębnionemu IFR mamy to, czego chcieliśmy. Możemy zobaczyć wszystkie ustawienia UEFI dostępne, w tym "Image Execution Policy".

Form FormId: 0x2A79, Title: "Image Execution Policy"
	Text Prompt: "Internal FV", Help: "", Text: "Always Execute"
	OneOf Prompt: "Option ROM", Help: "Image Execution Policy on Security Violation per Device Path", QuestionFlags: 0x10, QuestionId: 0x1116, VarStoreId: 0x28, VarOffset: 0x4, Flags: 0x10, Size: 8, Min: 0x0, Max: 0x5, Step: 0x0
		Default DefaultId: 0x0 Value: 0
		OneOfOption Option: "Always Execute" Value: 0
		OneOfOption Option: "Always Deny" Value: 1
		OneOfOption Option: "Allow Execute" Value: 2
		OneOfOption Option: "Defer Execute" Value: 3
		OneOfOption Option: "Deny Execute" Value: 4
		OneOfOption Option: "Query User" Value: 5
	End
	OneOf Prompt: "Removable Media", Help: "Image Execution Policy on Security Violation per Device Path", QuestionFlags: 0x10, QuestionId: 0x1117, VarStoreId: 0x28, VarOffset: 0x5, Flags: 0x10, Size: 8, Min: 0x0, Max: 0x5, Step: 0x0
		Default DefaultId: 0x0 Value: 0
		OneOfOption Option: "Always Execute" Value: 0
		OneOfOption Option: "Always Deny" Value: 1
		OneOfOption Option: "Allow Execute" Value: 2
		OneOfOption Option: "Defer Execute" Value: 3
		OneOfOption Option: "Deny Execute" Value: 4
		OneOfOption Option: "Query User" Value: 5
	End
	OneOf Prompt: "Fixed Media", Help: "Image Execution Policy on Security Violation per Device Path", QuestionFlags: 0x10, QuestionId: 0x1118, VarStoreId: 0x28, VarOffset: 0x6, Flags: 0x10, Size: 8, Min: 0x0, Max: 0x5, Step: 0x0
		Default DefaultId: 0x0 Value: 0
		OneOfOption Option: "Always Execute" Value: 0
		OneOfOption Option: "Always Deny" Value: 1
		OneOfOption Option: "Allow Execute" Value: 2
		OneOfOption Option: "Defer Execute" Value: 3
		OneOfOption Option: "Deny Execute" Value: 4
		OneOfOption Option: "Query User" Value: 5
	End
End

Sprawdziłem, czy inni producenci (ASRock, ASUS, Biostar, EVGA, Gigabyte i NZXT) mają to samo i nie udało mi się znaleźć niczego takiego w ich IFR. Również laptopy MSI nie są dotknięte tym problemem. Zakładam, że uznali, że Microsoft tego nie zaakceptuje i/lub że mieli mniej zgłoszeń od ludzi dotyczących problemów związanych z Secure Boot dla ich laptopów.

Robienie tego ręcznie byłoby trochę żmudne, więc zrobiłem mały mały skrypt w shellu, który sprawdza czy menu "Image Execution Policy" jest dostępne i czy któraś z trzech opcji jest ustawiona na "Always Execute".

#!/bin/sh

if [ ! -d "$1" ]; then
	[ ! -f "$1.zip" ] && curl "https://download.msi.com/bos_exe/mb/$1.zip" -O -#
	bsdtar xf "$1.zip"
fi

cd "$1" || exit
UEFIExtract ./*MS.* unpack 1>/dev/null
ifrextractor ./*.dump/Section_PE32_image_899407D7-99FE-43D8-9A21-79EC328CAC21_Setup_body.bin 1>/dev/null
output="$(grep -A1 -E 'OneOf Prompt: "(Option ROM|Removable Media|Fixed Media)", Help: "Image Execution Policy' ./*.dump/Section_PE32_image_899407D7-99FE-43D8-9A21-79EC328CAC21_Setup_body.bin.*ifr.txt)"
clear

if echo "$output" | grep -q "DefaultId: 0x0"; then
	printf "\033[1;31m%s: Bad\033[0m\n" "$1"
else
	printf "\033[1;32m%s: Good\033[0m\n" "$1"
fi

Na tym kończy się ta fajna część roboty. Teraz musiałem sprawdzić firmware dla wmiare nowych płyt od MSI.

Podczas gdy większość firmware'u możemy zdobyć po prostu wchodząc na stronę wsparcia płyty głównej stronie wsparcia, MSI zazwyczaj daje linki do stabilnych wersji firmware'u i najnowszą beta. Problem polega na tym, że muszę dowiedzieć się, kiedy zostało to dodane najwcześniej do firmware'u dla każdej płyty, co oznacza, że muszę zgadywać, jak nazywały się bety (jeśli w ogóle istniały). Przynajmniej MSI nie usuwa większości swoich beta firmware'ów z serwerów, więc są one nadal dostępne, jeśli znasz link.

Dla niektórych płyt AMD znalazłem listę beta firmware na jakimś niemieckim forum. Na szczęście nie musiałem czytać żadnego niemieckiego, bo wbrew powszechnej opinii, nie znam niemieckiego ani rosyjskiego, jestem Polakiem, na imigracji co prawda ale no.

To… trwało wieki. Sprawdziłem każdą płytę główną z chipsetem:

AMD: TRX40, X399, X670, X570, X470, X370, B650, B550, B450, B350, A520, A320
Intel: X299, Z790, Z690, Z590, Z490, Z390, Z370, B760, B660, B560, B460, B360, H670, H510, H410, H370, H310

To… jest wiele płyt głównych. Dla pełnej listy płyt głównych, których dotyczy ten problem i ich wersje firmware'u, odwiedź sbctl#181.

A teraz czas na jakąś "zabawną" (nie dla mnie) statystykę:

# Ilość razy jaki uruchomiłem skrypt
$ history 0 | grep "  msi " | wc -l
1989

Według Wikipedii w 1989:

W tym roku pojawili się pierwsi komercyjni dostawcy usług internetowych, jak również pierwsza pisemna propozycja dla World Wide Web oraz pierwsze połączenia internetowe w Nowej Zelandii, Japonii i Australii.

Cóż, to był błąd.

Można by zapytać, dlaczego tego nie zautomatyzowałem? Powodem jest… nie jest to zbyt proste, ponieważ niektóre nazwy bety mają arbitralne przyrostki co było szybsze dla mnie do zgadnięcia niż korzystanie ze skryptu który bruteforce'owałby te nazwy. Również niektóre płyty nie były wymienione na ich stronie z listą płyt głównych.

Teraz, po wykonaniu całej pracy dla MSI, myślę, że powinienem wystawić im rachunek, albo powinni mi dać dożywotni zapas płyt głównych.

Jeśli jesteś ciekawy, tak, próbowałem skontaktować się z MSI w tej sprawie, ale zignorowali moje emaile i inne formy komunikacji, których próbowałem.

EDIT: MSI wydało oświadczenie w tej sprawie. Najdziwniejsze jest to, że jest to tylko na ich subreddicie. I tak jak się domyśliłem, to była celowa zmiana.

Konkluzja

Nie ufaj, że jakiekolwiek zabezpieczenia, które włączyłeś, działają, PRZETESTUJ JE! W jakiś sposób byłem pierwszą osobą, która to udokumentowała, mimo że zostało to po raz pierwszy wprowadzone gdzieś w 3 kwartale 2021.

Czas na quiz!

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