Zanim serwer załaduje system operacyjny, zanim zadziała Secure Boot i zanim ktokolwiek zdąży sprawdzić, co właściwie się uruchamia, firmware już wykonuje swoją pracę. Właśnie w tym momencie można teraz uderzyć. Jak podaje Ars Technica, w kodzie TianoCore EDK II wykryto lukę o ocenie 9,5 na 10, oznaczoną jako CVE-2026-97631. EDK II to otwarty zbiór kodu, z którego korzystają producenci sprzętu i dostawcy chmury, budując firmware UEFI.
Wyciek zamiast koordynacji
Lukę znaleźli Alex Matrosov z Anthropic i Dan Holmes z Google. Zgodnie z planem miała pozostać tajemnicą do skoordynowanego ujawnienia w styczniu. Tymczasem AMI w zeszłym miesiącu opublikowało pull request, który opisywał podatność i zawierał poprawkę w kodzie. Gdy zwrócili na to uwagę odkrywcy, członkowie projektu TianoCore wydali w zeszłym tygodniu publiczny komunikat.
Ars Technica zwraca uwagę na konsekwencje: z dostępną publicznie łatką zaawansowani hakerzy mogą bez trudu zrozumieć, jak wywołać błąd, i zbudować działające exploity. A łatanie UEFI w milionach urządzeń sprzedawanych przez tysiące producentów i dostawców chmury jest żmudne i długie. To już drugie takie potknięcie w ciągu sześciu dni - wcześniej fiasko w ujawnieniu dotyczyło krytycznej luki w PHP.
Szesnaście lat w sterowniku
Błąd to przepełnienie bufora, któremu według Ars Technica jest 16 lat. Siedzi w sterowniku PXE Base Code (NetworkPkg/UefiPxeBcDxe), odpowiedzialnym za uruchamianie urządzeń z kodu pobieranego z sieci lokalnej. Sterownik nasłuchuje komunikatów o błędach ICMP i kopiuje je do pola o stałej długości 504 bajtów. Nie pilnuje jednak limitu, więc zbyt długi komunikat nadpisuje sąsiednie dane. Zgodnie z oficjalnym komunikatem pętla kopiująca błędnie obsługuje granice zarówno w obsłudze IPv4, jak i IPv6.
Złośliwy komunikat można dostarczyć zwykłym pakietem unicast na adres IP urządzenia, z dowolnej odległości w sieci, pod warunkiem że trafi w trwający rozruch PXE. Najprostszy skutek to zawieszenie rozruchu. Gdy atakujący zna wersję firmware'u celu, może wykonać kod w pierścieniu 0, czyli na najwyższym poziomie uprzywilejowania procesora.
HD Moore, twórca Metasploita i szef badań w firmie Dragos, mówi, że atakujący znajdujący się w pobliżu może przejąć przebieg programu w chwili, gdy rozruch ma jeszcze dostęp do wrażliwych komponentów, takich jak TPM. Według niego można w ten sposób złamać szyfrowanie dysku, jeśli napastnik ma krótkotrwały dostęp do sieci, a w przypadku kradzieży byłoby to jeszcze łatwiejsze. Dodaje, że przy tak powszechnym kodzie to prawdopodobnie „wieczny” błąd, który przetrwa w systemach po zakończeniu wsparcia.
Ile w tym realnego zagrożenia
Są ograniczenia. Atak wymaga kontroli nad fragmentem sieci lokalnej, więc najbardziej zagrażają mu osoby z wewnątrz albo napastnicy, którzy już zdobyli niski poziom dostępu i szukają podniesienia uprawnień. Na razie nie ma dowodów, że luka daje wejście do sieci z zewnątrz. Jesse Michael z firmy Eclypsium tłumaczy ponadto, że atakujący musi odgadnąć konkretne adresy w systemie, więc exploit trzeba dostrajać do modelu, wersji i konfiguracji. Zaletą jest to, że w odróżnieniu od BootHole czy BlackLotus wystarczy zwykła poprawka kodu i aktualizacja BIOS-u lub UEFI, bez unieważniania kluczy.
Luka nie dotyczy użytkowników domowych ani małych biur, a także tych, którzy uruchamiają sprzęt wyłącznie z dysków. Chodzi o organizacje z maszynami startującymi z sieci, przy włączonym PXE (domyślnie jest włączone) i firmware opartym na EDK II.
Intel odpowiedział mailowo, że żaden z jego produktów komercyjnych objętych obecnie wsparciem bezpieczeństwa nie jest znany jako podatny, bo nie zawiera funkcji EDK2 w swoim kodzie referencyjnym, choć może ją dołożyć producent płyt lub systemów. Arm uznał, że luka „nie dotyczy bezpośrednio” jego portfolio produktów. Ars Technica przypomina jednak, że kod obu firm obficie czerpie z EDK2. Pytania do AMD, Phoenix Technologies, AMI, Microsoftu i Amazona pozostały bez odpowiedzi.
Zalecenia są proste: zapytać producenta firmware'u o wskazówki, w miarę możliwości wyłączyć rozruch sieciowy choćby tymczasowo i obserwować logi. Włączone TPM i Secure Boot nie ochronią przed tym atakiem, bo błąd uderza, zanim zdążą zadziałać.
Wpis z pasa „W ruchu”, 28 października 2026. Na zdjęciu: Serwerownia firmy BalticServers.
