(in)Secure Boot MSI: Część 2
To jest kontynuacja "(in)Secure Boot MSI". 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 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.
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 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 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 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:
- Non-UEFI OS (= Always Execute (zawsze uruchamiaj) dla wszystkich urządzeń, ustawienie domyślne))
- 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.
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.