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

Inżynierowie Google mieli nosa, ostrzegającprzed nie tylko przed błędami w mechanizmach zdalnego zarządzaniakomputerem Intela, ale też przed analogicznymi własnościowymirozwiązaniami na platformie AMD. W październiku zeszłego rokuprezentując swoje minimalne linuksowe firmware NERF mówili – niewierzcie we wszystko, co przeczytaliście o Ryzenie. A terazokazuje się, że AMD Platform Security Processor (PSP) podatny jestna błąd przepełnienia bufora, pozwalający napastnikowi nawykonanie na nim własnego kodu i wydobycie przechowywanych tamdanych.

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

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

Niestety nie dowiedzieliśmy się, co faktycznie robi takieprzełączenie ustawienia i w którym momencie po uruchomieniusystemu zaczyna być brane pod uwagę. W najlepszym wypadku PSP jestwciąż aktywne i ma kontrolę nad komputerem do momentu załadowaniaBIOS-u. W najgorszym wypadku wciąż aktywne i potencjalnie groźnePSP po prostu przestaje „rozmawiać” z BIOS-em. Niestety, z tegoco piszą inżynierowie firmy ASRock wynika,że wprowadzona do ustawień UEFI opcja po prostu wyłącza sterownikPSP. Czy PSP przejmuje się tym wyłączeniem? A to już zupełnieinna kwestia – koprocesor bezpieczeństwa ma taką pozycję warchitekturze sprzętowej, że może po prostu zignorować wyłączniki powiedzieć użytkownikowi, że przełącznik działa. Jako żenikt 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 SecurityProcessorze. Korzystając z metod statycznej analizy kodu, odkryłbłąd w funkcji EkCheckCurrentCert. Jak wyjaśnia w swoim mailuna liście dyskusyjnej Full Disclosure dowodzi, że odpowiedniospreparowany certyfikat, przedstawiony procesorowi PSP, pozwalaprzepełnić bufor ze względu na brak sprawdzania zakresu.

Choć zabrzmi to paradoksalnie, nic więcej nie potrzeba, abyuruchomić własny kod na procesorze, który nazwano procesorembezpieczeństwa platformy. Cfir Cohen wyjaśnia, że w środowiskuPSP nie zastosowano żadnych technik neutralizacji exploitów, takichjak bity NX, randomizacja przestrzeni adresowej czy ciasteczka stosu.

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

Fani AMD słusznie zauważają, że odkryta w PSP podatność niejest tego samego kalibru, co w wypadku podatności w Intel ManagementEngine, wymaga bowiem lokalnego dostępu do maszyny. Z drugiej jednakstrony widać tu nadmierny optymizm i brak zrozumienia zagrożeń zestrony szpiegostwa przemysłowego. Musimy zakładać, że napastnikna jakimś etapie będzie miał dostęp do maszyny, nawet jeszczeprzed jej dostarczeniem do klienta. Jeśli jest w stanieprzeprogramować PSP, zainstalować na nim swój własny rootkit,ofiara nigdy się nie dowie, że działa na maszynie niegodnejzaufania.

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