Windows 10. Historia wadliwej aktualizacji jest dłuższa. Problemy trwały niemal rok

Opisane przez Piotra problemy z aktualizacją Secure Boot w ostatniej paczce aktualizacji okazują się być pokłosiem bardzo poważnych problemów z dostarczaniem i analizą bezpieczeństwa dla komponentu UEFI. Miejmy na uwadze fakt, że UEFI jest nie tylko (absurdalnie skomplikowanym) oprogramowaniem układowym, ale także pierwszym ogniwem w łańcuchu zaufania dzisiejszego modelu bezpieczeństwa.

Problemy w UEFI i Secure Boot są zatem, innymi słowy, potencjalnymi bombami unieważaniającymi architekturę zabezpieczeń. Gdy system operacyjny ma dziurę, to wysyła się do niego aktualizację, która ją likwiduje. Lecz jeżeli komponenty takie, jak TPM albo Secure Boot są dziurawe, to mamy problem: bardzo możliwe, że powodem jest nieprzemyślana architektura i problemu nie da się rozwiązać.

Specyfika problemów działających "w jedną stronę", gdzie da się raz zepsuć, ale naprawić się już nie da, to właśnie cecha charakteryzująca naprawiony nieszczęsną aktualizacją problem w Secure Boot. Mechanizm Bezpiecznego Rozruchu (Secure Boot, SB) polega na tym, że kod menedżera rozruchowego EFI musi być podpisany cyfrowo w sposób rozpoznawalny przez oprogramowanie układowe płyty głównej (w pewnym uproszczeniu). Oznacza to, że UEFI zawiera zbiór odwzorowań podpisów, które uznaje za zaufane. Jeżeli menedżer jest niepodpisany, został podpisany kluczem nieznanym płycie lub zmodyfikowano go, SB uznaje go za niebezpieczny i odmawia uruchomienia systemu.

To bardzo przydatna funkcje, acz pod kilkoma warunkami. Po pierwsze, i najmniej ważne(!), powinno być możliwe jej wyłączenie. Po drugie, dodawanie kluczy do bazy powinno być niemożliwe lub wymagać manualnej interwencji (co innego usuwanie!). Wreszcie, podmioty odpowiedzialne za podpisywanie menedżerów ładowania nie powinny rozdawać podpisów na prawo i lewo, stosując fikcyjny lub kiepski logistycznie proces weryfikacji. No cóż. Zgadnijmy, co właśnie miało miejsce.

Niezastąpiony ValdikSS dokonał w kwietniu zeszłego roku podsumowania swojej analizy dotyczącej możliwości stworzenia menedżera ładowania, który pozwala uruchamiać dowolny, niepodpisany kod. Domyślnie, z powodów licencyjnych na większości płyt głównych znajdują się tylko odciski podpisów menedżerów ładowania Windows 8 i Windows 10. Microsoft bardzo lubi taki układ, ale reszta świata niekoniecznie. Świat linuksowy stosuje kilka rozwiązań. Jednym z nich jest PreLoader autorstwa Linux Foundation. Pozwala on autoryzować menedżer tak, by działał w Secure Boot. Operacja ta wymaga ręcznej akceptacji. Jest też projekt Red Hata, rhboot, czyli podpisany wariant GRUB2.

Na podstawie wyżej wymienionych rozwiązań, ValdikSS stworzył obraz partycji rozruchowej, dzięki któremu da się zainstalować system na komputerach chronionych przez SB. Podczas uruchamiania obrazu, użytkownik musi przejść przez operację autoryzowania klucza. Potem można już ładować co się chce.

Wydaje się to być obejściem Secure Boot, które może zostać wykorzystane przez złośliwe oprogramowanie, ale nie do końca tak jest. Nawet gdy wirus podmieni menedżer ładowania, konieczne jest przejście przez proces autoryzacji klucza, a to zawsze jest operacją manualną. Większym problemem jest to, że wydawcą PreLoadera jest Microsoft, ale właścicielem – Linux Foundation. Niespodzianka. Najwyraźniej Microsoft jest podmiotem odpowiedzialnym za orzekanie, co jest legalne na platformie PC. Wintel wiecznie żywy.

Ten "manualny krok" podczas łamańców z PreLoaderem i jego wewnętrzną, druga bazą UEFI wciąż trzeba się bawić na tyle, że SB nie może zostać uznane za całkowicie przejęte. Aby możliwe było kompletne złamanie zabezpieczeń Secure Boot, musi być możliwe skłonienie jednego z podpisanych przez Microsoft menedżerów rozruchu do załadowania arbitralnego kodu. Windowsowy BOOTMGR dzielnie opiera się takim próbom od swojego powstania w 2006 na potrzeby przełomowego wynalazku o nazwie Windows Vista, ale są jeszcze inne menedżery które otrzymały błogosławieństwo z Redmond.

Jednym z nich jest Kaspersky Rescue Disk. Specjalne środowisko odzyskiwania przeznaczone do leczenia zainfekowanych systemów (tak, najwyraźniej są ludzie, którzy chcą "leczyć" system, zamiast od razu orać go do cna i stawiać na nowo). Rescue Disk Kaspersky'ego stosuje menedżer GRUB2, ale nie taki sam, jaki jest w menedżerze rhboot. Red Hat w swoim GRUB-ie wyłączył taką skromną i jakże pomijalną kwestię, jak... ładowanie modułów opcjonalnych. Kaspersky nie.

Artykuł powstał pierwszego kwietnia 2019 i zakończono go komentarzem, że prawdopodobnie luka nie pozostanie otwarta szczególnie długo. ValdikSS oczekiwał, że Forum UEFi zrobi użytek ze swojej globalnej listy odwoławczej, a Microsoft pośle ją przez Windows Update do klientów. Tak się jednak nie stało. Plik DBXUPADTE.BIN zawierający spis unieważnionych kluczy, dalej pochodzi z ósmego sierpnia 2016. Innymi słowy: [quote]W kwietniu zeszłego roku zidentyfikowano lukę unieważniającą Secure Boot, ale przez cały ten czas nikt się tym nie przejął.[/quote]

Po poinformowaniu zainteresowanych stron i nieotrzymaniu aktualizacji listy odwoławczej ani od Forum UEFI ani od Microsoftu, menedżer "Silent UEFIinSecureBoot Disk" został po ośmiu miesiącach (!!) umieszczony na rosyjskim RuTrackerze. Wtedy obudził się Kaspersky i poinformował, że współpracuje z Microsoftem celem dodania wpisu do listy odwoławczej i aktualizacja ukaże się w lutym.

W efekcie otrzymaliśmy aktualizację, która wywołała w tym tygodniu tyle bałaganu. Dodanie aktualizacji listy odwoławczej okazało się być problematyczne. Niektórzy użytkownicy nie mogli ukończyć instalacji łatki, ponieważ instalator nie potrafił się dogadać z oprogramowaniem układowym, ale zdążył w nim coś namieszać na tyle, że twardy restart informował o tym, że baza kluczy sie uszkodzona. Komputery HP z kolei mogły z kolei zakończyć instalację pozornie poprawnie, ale po restarcie krzyknąć, że baza jest uszkodzona. W konsekwencji Microsoft wycofał aktualizację KB4524244.

Trudno powiedzieć, kto tu zawinił. Czy Microsoft, tworząc aktualizację nieumiejącą rozmawiać z UEFI, czy też (co bardziej prawdopodobne) implementatorzy UEFI, którzy najwyraźniej tylko "mniej więcej" zastosowali się do standardu. Na pewno wtopą było unieruchomienie własnego mechanizmu przywracania, który w swojej kopii trzymał stary wariant menedżera. Niemniej, jest to kolejny argument za tym, żeby jednak aktualizować BIOS. Można podejrzewać, że przeczuwano problemy. Wydano ją bowiem, wbrew obyczajowi, jako oddzielna łatka, niezintegrowana z lutowym pakietem aktualizacji. Może chciano oszacować skalę niezgodności, żeby postraszyć dostawców?

Z powodu problemów, aktualizację wycofano. Jeżeli ktoś ją zainstalował i Secure Boot mu nie działa, może ją usunąć i problem powinien zniknąć. Jeżeli ktoś nie natknął się na żadne problemy, to należy do zbioru osób chronionych przez złośliwymi menedżerami rozruchu. Aczkolwiek należy pamiętać o tym, że malware wykorzystujący ową podatność byłby ciężki, wymagający praw administracyjnych i bardzo charakterystyczny, przez co ryzyko infekcji zawsze było bardzo niskie.

Przy okazji wyszła jednak na jaw pewna impotencja Forum UEFI. Lista członków, promotorów, implementatorów oraz kontrybutorów ciągnie się na wiele ekranów, ale efektywnie to Microsoft i jego Windows Update okazują się być autorytatywnym źródłem informacji na temat listy menedżerów uznawanych za bezpieczne dla platformy PC. W czasach, w których istnieją materiały, jak "Managing Surface UEFI BIOS settings with Microsoft Intune" jest to dość przerażające. Powołany komitet okazuje się być zależny od jednej firmy, a i tak łatanie dziur zajmuje mu osiem miesięcy. W połączeniu z absolutną plagą nieaktualnego oprogramowania układowego, jest to bardzo przykra sytuacja.

Skontaktowaliśmy się z Forum UEFI, kierując pytanie o odpowiedzialność za listę odwoławczą. Wrócimy do tematu po otrzymaniu odpowiedzi. Mechanizm raportowania incydentów bezpieczeństwa wygląda na rozbudowany. Być może przetwarzanie pytań biurokratycznych działa równie sprawnie. Oby nie przyszło czekać na odpowiedź osiem miesięcy.