Niepodpisany firmware zagraża nowym laptopom. Problemu nie da się rozwiązać

Aktualizacja oprogramowania układowego, jak BIOS, była dzięki programowalności układów dostępna już od bardzo dawna. Wiele płyt głównych oraz bardziej złożonych peryferiów umożliwa zainstalowanie ("flash") nowego kodu układowego za pomocą niekoniecznie udokumentowanych, ale jednak jawnych lub możliwych do wykrycia mechanizmów.

Skoro zatem układ jest programowalny, z definicji możliwe jest umieszczenie w nim złośliwego kodu, prawda? Czyżby case closed i całe "odkrycie" było jedynie hałaśliwym stwierdzeniem oczywistości? Nie do końca. Jak omawiamy w naszej serii na temat zabezpieczania komputera (w następnym odcinku podatności AMT!), dzisiejsze urządzenia są bardzo rozbudowaną elektroniką i jej mechanizmy aktualizacji również są dość złożone.

To już nie czasy "dyskietki z aktualizacją mikrokodu", uruchamiającej komputer do MS-DOS 7.0 z automatycznie startującym FLSHTOOL.EXE (choć niniejsze słowa piszę właśnie na sprzęcie takiej klasy). Dziś proces aktualizacji takich urządzeń jak płyta główna, karta sieciowa lub koncentrator Thunderbolt przebiegają za pomocą dedykowanych wywołań sprzętowego API.

Oznacza to, że przy takiej skali złożoności, całkowicie możliwe jest zaimplementowanie mechanizmu, który zaakceptuje nie tylko kod z właściwą sumą kontrolną, ale także z właściwym podpisem cyfrowym. Takiej weryfikacji dziś brakuje. Aby zabezpieczyć, logistycznie mówiąc, cały "łańcuch dostaw", kontrolą podpisu musiałyby być objęte następujące składniki:

• Instalator pakietu (podpisany cyfrowo)
• Narzędzie aktualizujące firmware (podpisane cyfrowo)
• Firmware (zawierający podpis wymagany przez narzędzie)
• Układ (przyjmujący tylko podpisany firmware)

Praktyka pokazuje, że najczęściej podpisem są objęte tylko dwa pierwsze elementy. Podobnie sprawa ma się ze sterownikami. Duża liczba bezprzewodowych kart sieciowych wymaga załadowania własnościowego bloba binarnego celem aktywacji. Zmodyfikowanie sterownika w Windows wywoła błąd ochrony i odrzucenie takiego pliku, ale gdy to załadowany sterownik odpowiada na "łańcuchowe" załadowanie zbiorów binarnych do samego urządzenia, to odpowiedzialność za sprawdzenie jego poprawności spoczywa na nim. System tego już nie pilnuje, i jak się okazało, sterowniki często też nie.

Eclypsium przedstawiło teoretyczną klasę problemów bezpieczeństwa, których źródłem jest słabość logistyczna, a nie ściśle "programistyczna". Poza zdefiniowaniem ogólnego zagrożenia, dostarczyli też gotowy przepis na atak konkretnych urządzeń. Nawiązano także do kategorii naruszeń opartych o dostęp DMA, którego tematem również wkrótce się zajmiemy.

Ponieważ weryfikacja podpisu jest potrzebna na poziomie sprzętowym, luki nie da się załatać. Konieczna jest zatem kontrola pozostałych elementów łańcucha dostaw, czyli odebranie użytkownikom praw do modyfikowania plików ze sterownikami, uruchamianie wyłącznie znanych programów (badanym kamerom Sunplus da się zmienić firmware mając tylko prawa użytkownika!) i aktualizacja oprogramowania. Antywirus nie zaszkodzi. Trudno jednak o pewność, że pomoże.