reklama

Błąd w procesorze bezpieczeństwa AMD pozwala na atak złośliwym certyfikatem

Strona główna Aktualności

O autorze

Hodowca maszyn wirtualnych i psów, poza tym stary linuksiarz, bonvivant i śmieszek. W 2012 roku napisał na DP o algorytmie haszowania Keccak i wciąż pamięta, jak on działa.

Inżynierowie Google mieli nosa, ostrzegając przed nie tylko przed błędami w mechanizmach zdalnego zarządzania komputerem Intela, ale też przed analogicznymi własnościowymi rozwiązaniami na platformie AMD. W październiku zeszłego roku prezentując swoje minimalne linuksowe firmware NERF mówili – nie wierzcie we wszystko, co przeczytaliście o Ryzenie. A teraz okazuje się, że AMD Platform Security Processor (PSP) podatny jest na błąd przepełnienia bufora, pozwalający napastnikowi na wykonanie na nim własnego kodu i wydobycie przechowywanych tam danych.

PSP to niezależny koprocesor bezpieczeństwa z rdzeniem ARM, zawierający własną pamięć operacyjną, odizolowaną nieulotną pamięć do przechowywania wrażliwych danych, silnik kryptograficzny, kontroler zasobów sprzętowych komputera i osadzoną w krzemie logikę do kontroli rozruchu platformy x86. Działa na nim jego własny system operacyjny i podobnie jak w wypadku Intel Management Engine, jego istnienie budzi obawy tych, którzy noszą czapeczki z folii aluminiowej i twierdzą, jakoby służby wywiadowcze mocarstw włamywały się do komputerów za pomocą nieznanych nikomu innemu exploitów.

W grudniu AMD ogłosiło, że wychodzi naprzeciw postulatom społeczności i pozwala z poziomu ustawień UEFI/BIOS wyłączyć PSP w swojej platformie AM4 (na której działają Ryzeny). Wybrano na to dobry dla wizerunku firmy moment – wszyscy rozmawiali o odkrytych przez rosyjskich badaczy lukach w Intel Management Engine (ME), a Intel zamiast zaoferować możliwość łatwego wyłączenia tego mechanizmu, po prostu wydał łatki.

Niestety nie dowiedzieliśmy się, co faktycznie robi takie przełączenie ustawienia i w którym momencie po uruchomieniu systemu zaczyna być brane pod uwagę. W najlepszym wypadku PSP jest wciąż aktywne i ma kontrolę nad komputerem do momentu załadowania BIOS-u. W najgorszym wypadku wciąż aktywne i potencjalnie groźne PSP po prostu przestaje „rozmawiać” z BIOS-em. Niestety, z tego co piszą inżynierowie firmy ASRock wynika, że wprowadzona do ustawień UEFI opcja po prostu wyłącza sterownik PSP. Czy PSP przejmuje się tym wyłączeniem? A to już zupełnie inna kwestia – koprocesor bezpieczeństwa ma taką pozycję w architekturze sprzętowej, że może po prostu zignorować wyłącznik i powiedzieć użytkownikowi, że przełącznik działa. Jako że nikt poza producentem nie ma dostępu do kodu źródłowego, bezpieczeństwo zostaje sprowadzone do zaufania.

A teraz Cfir Cohen, badacz z Google Cloud Security Team, zademonstrował pierwszą podatność tkwiącą w Platform Security Processorze. Korzystając z metod statycznej analizy kodu, odkrył błąd w funkcji EkCheckCurrentCert. Jak wyjaśnia w swoim mailu na liście dyskusyjnej Full Disclosure dowodzi, że odpowiednio spreparowany certyfikat, przedstawiony procesorowi PSP, pozwala przepełnić bufor ze względu na brak sprawdzania zakresu.

Choć zabrzmi to paradoksalnie, nic więcej nie potrzeba, aby uruchomić własny kod na procesorze, który nazwano procesorem bezpieczeństwa platformy. Cfir Cohen wyjaśnia, że w środowisku PSP nie zastosowano żadnych technik neutralizacji exploitów, takich jak bity NX, randomizacja przestrzeni adresowej czy ciasteczka stosu.

Podatność została odkryta pod koniec września zeszłego roku i odpowiedzialnie przekazana do AMD Security Team. 7 grudnia ukończono prace nad łatką. AMD pracuje nad jej przekazaniem partnerom, którzy poprzez aktualizację firmware dostarczą ją użytkownikom. Niestety jak do tej pory aktualizacje takie się nie pojawiły.

Fani AMD słusznie zauważają, że odkryta w PSP podatność nie jest tego samego kalibru, co w wypadku podatności w Intel Management Engine, wymaga bowiem lokalnego dostępu do maszyny. Z drugiej jednak strony widać tu nadmierny optymizm i brak zrozumienia zagrożeń ze strony szpiegostwa przemysłowego. Musimy zakładać, że napastnik na jakimś etapie będzie miał dostęp do maszyny, nawet jeszcze przed jej dostarczeniem do klienta. Jeśli jest w stanie przeprogramować PSP, zainstalować na nim swój własny rootkit, ofiara nigdy się nie dowie, że działa na maszynie niegodnej zaufania.

Dlatego tak słuszne są ostrzeżenia twórców coreboota: obecna struktura UEFI służy tylko temu, aby producenci zachowali kontrolę nad użytkownikiem. Niestety nikłe szanse, że w dostępnym na sklepowych półkach sprzęcie zobaczymy wolne i otwarte rozwiązania takie jak coreboot. Google własnymi siłami na swoich serwerach może wdrażać minimalny linuksowy system rozruchowy NERF, ale większość z nas skazana jest po prostu na zaufanie producentowi – czy to Intelowi, czy AMD.

© dobreprogramy
reklama

Komentarze

reklama