Szykują się kolejne luki w UEFI. O poprawkach wiadomo niewiele

Aktualizacje tak fundamentalnego oprogramowania są w dodatku nieprzeciętnie kłopotliwe. W hierarchii aktualizacji, oprogramowanie BIOS bardzo często znajduje się przecież na samym dole. System Windows potrafi z akceptowalną skutecznością regularnie aktualizować sam siebie, Sklep lub wbudowane narzędzia zajmują się w międzyczasie dbaniem o świeżość wersji pozostałego oprogramowania. Nieco większy problem jest ze sterownikami: coraz większa ich liczba potrafi być zaserwowana przez usługę Windows Update, dostawcy OEM mają wręcz obowiązek publikowania tam swoich sterowników, ale często zdarza się, że te najbardziej „niskopoziomowe” pozostają wieczyście nieaktualne.

Mowa tu o oprogramowaniu wbudowanym w układ scalony, czyli firmware. Jest ono coraz częstszym gościem w komputerach, ze względu na rosnącą złożoność chipów wchodzących w skład systemu komputerowego. Niegdyś, podzespoły wymagające oddzielnych układów scalonych wykorzystywały proste kontrolery, nierzadko jednokrotnego programowania. Aby zaktualizować ich działanie, należało je wydłubać i zastąpić nowymi. Późniejsze układy były wielokrotnie programowalne, ale zazwyczaj dostarczały funkcjonalność na tyle elementarną, że ich producent nie wydawał do nich aktualizacji. Kostki wbudowane np. w karty sieciowe zapewniały jedynie podstawowy zestaw opcji i były „zbyt głupie”, by wyrządzić szkodę lub uzyskać i zrozumieć dostęp do innych zasobów komputera. Cyfrowe karty dźwiękowe z kodekiem audio zawierały już układy o wiele mądrzejsze, ale przez swoje ograniczenie funkcjonalne nie stanowiły zagrożenia i nie były przeznaczone do aktualizacji (choć i te czasy już minęły).

Problem zaczął się w „czasach nowożytnych”: dzisiejsze komputery zawierają bardzo skomplikowane oprogramowanie układowe zwane UEFI. *Unified Extensible Firmware Interface * to potężnie rozbudowana specyfikacja oprogramowania kontrolującego sprzęt, I/O oraz ochronę systemu. UEFI znacznie wykracza swoją złożonością z ram ustanowionych niegdyś przez BIOS, a ze względu na swoją gigantyczną definicję, stanowi ciężkie wyzwanie dla producentów sprzętu, usiłujących dokonać implementacji UEFI w swoich urządzeniach.

Nie jest to jedyny układ o porażająco wysokiej złożoności. W ustroju sprzętowym PC pojawiają się kolejne wynalazki, jak np. kontroler Thunderbolt 3, inteligentny chip negocjujący zabezpieczoną i licencjonowaną komunikację z urządzeniami podpinanymi przez USB-3. Thunderbolt potrafi uzyskać niskopoziomowy dostęp do magistrali PCI Express i USB, dzięki czemu oferuje np. obsługę stacji dokujących podłączanych kablowo. Przy okazji jednak, wymusza surową dbałość o bezpieczeństwo. A z tym producent magistrali, Intel, najwyraźniej ma problem. Zresztą poza Thunderboltem jest jeszcze kilka innych zabawek, jak TPM.

Celem jak najszybszego dostarczenia wizualnie urzekających funkcji (wielomonitorowe doki podpinane jednym kabelkiem!), porzucono pryncypium KISS, zamiast tego zdając się wieczną pogoń za bezpieczną implementacją super-rozbudowanych standardów.

Ponieważ UEFI dostarcza tak wiele funkcji, jego aktualizacje wychodzą porażająco regularnie (o ile sprzęt nie jest z najniższej półki). Często jednak są ignorowane przez administratorów. Co gorsza, jedynie skromny podzbiór urządzeń, np. Microsoft Surface, potrafi pobrać i zaktualizować swój firmware przez Windows Update. Dlatego też UEFI, z konieczności przeprowadzania półautomatycznych, a czasem nawet ręcznych instalacji, nie jest aktualizowane jeżeli dziennik zmian opisuje np. 300 poprawek błędów w Panelu Overclockingu oraz nowe wersje tłumaczeń w języku katalońskim i gruzińskim. Poza tym aktualizacja UEFI to problem: pod pewnymi warunkami (za każdym razem innymi!), system operacyjny może zacząć twierdzić że jest uruchamiany na obcym komputerze i zablokować się przez Secure Boot. Lub poprosić o klucz odszyfrowujący BitLocker.

Dlatego, gdy okazuje się, że oto trzeba zaktualizować wszystkie obsługiwane urządzenia i na kilkuset laptopach w organizacji ma się pojawić nowe UEFI, zaczyna się bilansowanie zysków i strat. Może luka jest trudna do wykorzystania? Może wymaga fizycznego dostępu do urządzenia? I tak dalej. Z pomocą przychodzi wtedy Rejestr Podatności CVE, przedstawiający rodzaj i wagę słabości odkrytej w oprogramowaniu. Istotnie, i tym razem HP Enterprise uraczył odbiorców zestawem numerków z artykułami opisującymi naprawiane luki. Tym razem są to: CVE-2018-12201, CVE-2018-12202, CVE-2018-12203, CVE-2018-12204, CVE-2018-12205. Czyli aż pięć! Gdy jednak zajrzymy do pierwszej z brzegu, okazuje się że…

Wpis w Rejestrze CVE jest oznaczony jako zarezerwowany. Oznacza to, że podatność istnieje, została wejściowo zbadana i (prawdopodobnie) oceniona, ale z nieokreślonych powodów nie opublikowano szczegółów na jej temat, zobowiązując się zarazem do uczynienia tego w najbliższej przyszłości. W jaki sposób zatem ocenić, czy łatane podatności są istotne i czy warto poświęcać zasoby na wdrożenie aktualizacji? Należy wykorzystać poszlaki. Jeżeli podatność nie jest ogłoszona, to czasem oznacza to ograniczenia wynikające z licencji na zbadane oprogramowanie. Częściej jednak przeciągająca się rezerwacja oznacza problem na tyle istotny, że producenci potrzebują czasu, by stworzyć aktualizację. Jednocześnie skala problemu wymusza klauzulę tajności, ponieważ bez niej powstałoby złośliwe oprogramowanie bez znanych metod przeciwdziałania mu.

Trudno stwierdzić na podstawie samej daty, jaka jest powaga problemu. Notatki 12201 do 12205 zostały zarezerwowane już w czerwcu 2018! Czy to znaczy, że w implementacji UEFI od HP od pół roku znana jest luka, której nie wolno opublikować? Niestety, nie. Proces rezerwacji notatek CVE może być dokonywany „na zapas”. Red Hat dorocznie zamawia sobie np. 500 – na wszelki wypadek. Potem je zwalnia, ale zawsze udaje mu się kilkaset jednak wypełnić. Możliwe więc, że powyższe identyfikatory zostały zarezerwowane już wcześniej: identyfikatory aż od 12117 zostały zaalokowane tego samego dnia, więc możliwe, że dopiero teraz następuje ich „rozdysponowanie”. Niestety, nie dowiemy się tego. Czyli nasza ocena jest utrudniona.

Na szczęście, równolegle z HP Enterprise aktualizacje UEFI, również w podejrzanie obfitych ilościach, zaczęło publikować Lenovo. Dziennik zmian nowego oprogramowania układowego zawiera informację o łatkach na podatności 12201 i 12203, wprowadzanych wskutek wciągnięcia „łaty IB06740650 na kod do PCR”. Ta koszmarna numeromania i kosmiczne skróty okazują się jednak nieść strzęp informacji na temat specyfiki nieujawnionych jeszcze podatności. Komponent PCR jest bowiem składnikiem standardu TPM, kolejnego układu scalonego na płytach nowoczesnych komputerów. Układ ten jest odpowiedzialny za wyprowadzanie czynności składających się na tworzenie kluczy kryptograficznych poza główny procesor i de facto poza system operacyjny, celem zwiększenia bezpieczeństwa. Układ TPM przechowuje też klucze oraz unikatowe odciski stanu: na przykład wyciąg z odcisku palca albo źródło kryptograficzne dla narzędzi LUKS lub BitLocker. Pozwala to założyć, że wyżej wymienione podatności dotyczą jakiejś metody wykradnięcia prywatnej części owych szyfrów.

Jak to działa i jak to możliwe? Rejestry PCR wykazują cechę podobną do certyfikatów SSL: da się je łączyć w łańcuchy, podpisując kolejne certyfikaty poprzednimi. Jakiekolwiek naruszenie integralności narusza spójność całego łańcucha i unieważnia podpis na samym końcu ścieżki. Podobnie działają rejestry PCR, gdzie każda kolejna wartość „rozszerza” poprzednią. Jeżeli którakolwiek z wartości po drodze ulegnie zmianie, unieważnia do łańcuch zaufania. TPM jest karmiony „pomiarami”, z których wyciąg (hash) jest przechowywany w TPM. Każdy kolejny pomiar rozszerza poprzedni. System Windows w ramach pomiarów dostarcza informacji o sprzęcie, wersji oprogramowania układowego oraz wersji swojego menedżera ładowania (bootloader). Z każdego takiego pomiaru obliczany jest wyciąg. Wyciągi owe nachodzą na siebie: drugi jest obliczany z drugiego pomiaru i z pierwszego wyciągu i tak dalej.

Oznacza to, że sam układ TPM nie zawiera danych („prześlij mi wartość 1234, to uznam, że cię znam!”). Zawiera on jedynie wyciągi z owych danych, a na ich podstawie nie da się odkręcić, z jakich to danych powstały.

Posiadając tak stworzony zestaw wartości rejestrów PCR, podczas każdego kolejnego uruchomienia komputera, TPM na nowo dokonuje pomiarów i próbuje wyliczyć z nich nowy łańcuch. Jeżeli różni się on od tego, który znajduje się w „uzbrojonych” rejestrach, oznacza to że zawartość i/lub stan systemu został zmodyfikowany poza komputerem. Np. ktoś wyciągnął dysk twardy i próbował coś na nim dopisać. Albo wirus zmodyfikował bootloader po to, by przed startem antywirusa załadować sterownik kradnący naciśnięcia przycisków, celem wyłudzania haseł. Wirus może próbować być mądry i zastąpić rejestry PCR innymi. Ale by zresetować wpisy w TPM i zastąpić je własnymi, sfałszowanymi, potrzebny jest restart systemu. Z kolei zrestartowany system UEFI, gdy zobaczy zmianę w TPM… również zgłosi naruszenie integralności, prowadząc do identycznego stanu, jak przy ordynarnej infekcji. A więc cóż za fantastyczne rozwiązanie! Proste, a zarazem genialne. W dodatku funkcje sum kontrolnych i natura kryptografii asymetrycznej sprawiają, że sfałszowanie stanu TPM jest niemożliwe.

Niestety, nie jest tak pięknie. Mimo solidnych założeń, standard TPM jest bardzo rozległy, przez co pozostawia nieco zbyt wiele pola manewru w implementacji. Istnieje na przykład rozdział poświęcony procesowi przywracania stanu TPM podczas wybudzania się ze stanu wstrzymania (S3 Sleep). Rozdział ten nie pokrywa jednak scenariusza, w którym komputer wychodzi ze wstrzymania S3, ale nie posiada stanu TPM do przywrócenia. Okazuje się, że wiele układów pozwala wtedy na ponowne zainicjalizowanie TPM swoimi danymi (na które przecież układ czeka w ramach wybudzania). To typowy rodzaj luki umykającej recenzentom: skupiają się na obsłudze stanów dozwolonych, zapobieganiu stanom zakazanym, ale nie poświęcają uwagi stanom nieokreślonym. Niech rzuci kamieniem każdy programista, który nigdy nie przeoczył takiej słabości na recenzowanym przez siebie pull requeście. Powyższa podatność została zaklasyfikowana jako CVE-2018-6622 i przedstawiona jako referat wygłoszony na Sympozjum Bezpieczeństwa USENIX w sierpniu.

Biuletyny bezpieczeństwa HP milczą. Najnowszy, wydany już nowych BIOSach, dotyczy czego innego. Czyżby dalej trwało embargo? Prawdopodobnie dopiero w ciągu najbliższych tygodni poznamy detale dotyczące słabości w TPM i zapewne będą one podobnego „kalibru”, co wyżej wymieniona sztuczka ze stanem wstrzymania. Co bardziej niepokojące, problemy nie wynikają jedynie z błędnej/niechlujnej implementacji, ale z braków w samej definicji standardu TPM 2.0. Być może tym razem będzie podobnie. Nawet najlepsza implementacja dokonana przez fachowców może zostać zniweczona, jeżeli referencyjny standard jest słaby. Mamy już zasadne wątpliwości w kwestii TPM 2.0, nie dowiemy się jednak, czy jego implementacja jest słaba, czy nie. Wspomniana „łatka IB06740650”, na temat której wygadali się Chińczycy, to identyfikator wersji UEFI autorstwa innej chińskiej firmy: Insyde. Próżno szukać tam jakichkolwiek ogłoszeń na temat owej łaty, czy jakiejkolwiek łaty i jakiegokolwiek BIOSu. Wyjąwszy dziennik zmian od Lenovo, numer IB06740650 zwraca zero wyników w Google. Możemy też zapomnieć o źródłach i w praktyce o wszelkim sprzęcie komputerowym opartym o otwarty BIOS.

Czeka nas zatem interesująca przyszłość. Na pokładzie z UEFI, kontrolerem Thunderbolt, TPM oraz nieodżałowanym Intel Management Engine. Ciekawe, ile identyfikatorów CVE wypełnią one w tym roku…?