Intel potwierdza: wykradziono kod źródłowy BIOS-u platformy Alder Lake

Według potwierdzenia przesłanego przez Intela do serwisu Tom's Hardware, któraś z firm trzecich współpracujących z producentem platformy nie dopełniła wymogów bezpieczeństwa, co zakończyło się kradzieżą kodu. Jest on objęty rygorystycznym NDA i dostępny tylko producentom sprzętu, systemów operacyjnych i niektórych kompilatorów.

Wielka paka kodu pojawiła się (łamiąc oczywiście zasady serwisu) na portalu GitHub, co ogłoszono anonimowo w wątku na tablicy /g/ imageboardu 4chan. To kolejny już wyciek ogłaszany przez 4chana. Pojawiały się tam już źródła Xboksa, Windows XP i wielu projektów Nintendo. Niektóre były spektakularne (i zakończone aresztowaniami), inne przeszły bez echa.

Intel wydał zaskakujące oświadczenie, w którym potwierdził wyciek, stwierdził że publikacja kodu nie stanowi zagrożenia bezpieczeństwa, a tak w ogóle to cały kod jest dostępny w ramach ograniczonego programu Bug Bounty. I jeżeli ktoś znajdzie dziury w zabezpieczeniach, to niech śmiało zgłasza, ale obrót kodem poza programem łamie licencję.

Rzeczywistej zawartości paczki przyjrzał się jednak rosyjski badacz Mark Ermolov. Szybko doszedł do wniosku, że problemy z zabezpieczeniami jednak występują. Jednym z nich jest obecność klucza prywatnego używanego do podpisywania rdzenia zaufania dla... BootGuard, intelowskiej implementacji Secure Boot. Klucza na takim poziomie nie da się unieważnić, ponieważ "poleci" wszystko niżej w hierarchii. W rezultacie BootGuard nie jest już zaufany.

Innymi "położonymi" technologiami są Trusted eXecution Technology (TXT) oraz SGX, przynajmniej dla niektórych procesorów. Ciekawszy jest jednak wyciek nieudokumentowanych interfejsów MSR (Model-Specific Register). Interfejs ten jest wykorzystywany przez mikrokod CPU i nie jest przeznaczony do powszechnego użytku, ze względu na bezpieczeństwo i stabilność.

Mikrokod implementuje erratę do procesora: w ograniczonym stopniu wpływa, programowo, na działanie CPU które okazało się błędne i, ponieważ błędy popełniono "w krzemie", rzeczywista naprawa wymagałaby inaczej wymiany sprzętu. Nie da się wykonywać na procesora Intela kodu bardziej uprzywilejowanego niż mikrokod. Jego działania nie widzi nawet system operacyjny.

Są też dobre wieści: nie wyciekły klucze do podpisywania całej platformy. Oznacza to brak możliwości tworzenia "lewych" UEFI, mikrokodów i sterowników, potencjalnie akceptowanych przez sprzęt jako pochodzące od Intela. Tego rodzaju wyciek otworzyłby drogę do tworzenia wszechmocnych, niewykrywalnych rootkitów. Niektóre z nich mogłyby pracować w warstwie sprzętowej. Oprogramowanie antywirusowe potrzebowałoby adaptacji, by je wykryć.

Wyciek jest także pouczający z innych powodów. Obecność plików producentów UEFI dla głównych marek komputerów pokazuje, że aby stworzyć firmware dla peceta, konieczna jest współpraca z Intelem. Nie da się, w ramach oddolnej inicjatywy, stworzyć w pełni zgodnej, otwartej implementacji obecnej platformy PC.

Nawet podejście clean room engineering odpada, ze względu na patenty. System komputerowy oparty w całości o wolne oprogramowanie, prawdziwie otwarty i zgodny z najnowszą generacją CPU, jest więc nieosiągalny.