AMD wyda łatki na 13 luk w procesorach Ryzen znacznie szybciej, niż straszono

Mark Papermaster, dyrektor techniczny AMD, kolejno opisujegrupy zagrożeń, potencjalny wpływ na użytkowników i planowaneśrodki zaradcze, podkreślając, że nic z omawianych tu problemównie dotyczy samej architektury Zen, nie jest też związane zexploitemujawnionym w styczniu przez badaczy Google Project Zero. Problemydotyczą wyłącznie firmware procesora bezpieczeństwa (PSP)wbudowanego w podatne produkty, oraz czipsetów niektórych płytgłównych AM4/TR4. Co za tym idzie, żadna z wydanych łatek nie będzie miała wpływu na wydajność systemów z procesorami AMD.

Papermaster przypomina też, że wyexploitowanie każdej zewspomnianych luk wymaga dostępu administracyjnego, a przecież jeślimalware uzyska taki dostęp, to koniec. Musimy tutaj jednakpodkreślić, że to jedynie PR-owe zagranie. Ataki pozwalające napodniesienie uprawnień zdalnie uruchomionego kodu są znane nie oddzisiaj, uzyskiwanie uprawnień administracyjnych przez malware niejest niczym nowym, a najważniejsze tu jest to, że skuteczny atakpozwala szkodnikowi uzyskać trwałą obecność w systemie –będzie nieusuwalny przez normalne oprogramowanie antywirusowe,ukryty w pamięci procesora bezpieczeństwa.

Wracając jednak do grup zagrożeń, oto co AMD mówi i cozamierza zrobić:

• Luki MASTERKEY: napastnik, który naruszył już bezpieczeństwosystemu może zaktualizować firmware i zepsuć jego zawartość –procesor bezpieczeństwa nie wykryje tego zepsucia. Zmiany sątrwałe, przetrwają restart systemu. AMD pracuje nad aktualizacjamifirmware PSP, które wyda w najbliższych tygodniach i które usuniete podatności.
• Luki RYZENFALL i FALLOUT: napastnik, który naruszył jużbezpieczeństwo systemu może pisać do rejestrów PSP, abywykorzystać podatności w interfejsie pomiędzy PSP i procesoremx86. Pozwala mu to obejść kontrolę bezpieczeństwa platformy izainstalować trudne do wykrycia malware w pamięci SMM. AMD pracujenad aktualizacjami firmware PSP, które wyda w najbliższychtygodniach i które usunie te podatności.
• Luka CHIMERA w czipsecie Promontory: napastnik, który naruszyłjuż bezpieczeństwo systemu może zainstalować złośliwysterownik, który ujawnia pewne funkcje czipsetu, pozwalające nazainstalowanie w nim trudnego do wykrycia malware. AMD współpracujez firmą trzecią, która zaprojektowała i wyprodukowała podatnyczipset nad usunięciem tych podatności.

Warto podkreślić, że nie licząc Chimery, wszystkie podatnościmają być naprawione w ciągu najbliższych tygodni. Ośmiesza towcześniejsze twierdzenia Yarona Luk-Zilbermana z CTS Labs,deklarującego, że i tak zwyczajowe 90 dni na załatanie luk niczegoby nie zmieniło, *ponieważ i tak minie wiele miesięcy, zanim AMDzdoła je załatać. *Przypomnijmyzaś, że CTS Labs wzywałodo nowego standardu ujawniania luk w oprogramowaniu, w którym toinformacje o zagrożeniu, bez szczegółów technicznych,przedstawiane są już publicznie pierwszego dnia, tylko po to, abywywrzeć presję na producencie.

Przy okazji wostatnich dniach wyszła jeszcze jedna sprawa, która wzmacnia teorięo powiązaniach CTS Labs z Intelem. Izraelscy badacze pisząc o luceCHIMERA wspomnieli o czipach chińskiej firmy ASMedia (ASM1042,ASM1142, ASM1143), używanych jako kontrolery hostów USB 3.0/3.1.Furtki w tych czipach miały zostać odkryte na długo zanim bazującena nich kontrolery hosta (o niemal takim samym firmware) zaczęłybyć stosowane na płytach głównych Ryzenów – jednak CTS Labssiedziało cicho i nikogo nie alarmowało. Czemu? Przecież z tychsamych czipów do dzisiaj powszechnie korzysta się na płytachgłównych dla procesorów Intela!

UjawnienieChimery w kontekście luki w rozwiązaniach AMD, bez wspomnienianawet że ten sam błąd występuje na wielu płytach głównychIntela oraz niezależnych kartach rozszerzeń PCIe, nie ma żadnegousprawiedliwienia. Albo chodziło rzeczywiście o zagranie nawartości akcji AMD, albo była to próba zaszkodzenia konkurencji zestrony ludzi powiązanych z firmą trzecią, której nazwy oczywiścienie wymienimy. Luk-Zilberman oczywiście tego nie skomentował.

Niech jednak niktnie myśli, że ta sprawa w jakiś sposób rozgrzesza AMD. Czerwonisą winni tego samego, co ich wielki konkurent – zmusili nas dozaakceptowania w imię „większego bezpieczeństwa” PlatformSecurity Processora, zamkniętego, pozasystemowego rozwiązania, wktórym nikt nie wie co się dzieje. Wbudowany w Ryzeny ARM-owy rdzeńCortex-A5, mający to „większe bezpieczeństwo” zapewnić,okazał się po raz kolejny głównym zagrożeniem dla całejplatformy.

Tymczasem nie mamy ani kodu źródłowego, anidokumentacji, ani nawet pewnej metody neutralizacji PSP. W wypadkuIntel Management Engine przynajmniej można zniszczyć kluczowemoduły tego koprocesora bezpieczeństwa za pomocą narzędziaME_cleaner,tymczasem w wypadku PSP niczego takiego nie mamy. Owszem, AMDobiecujemożliwość „wyłączenia” w ustawieniach UEFI koprocesora, alejak działa takie wyłączenie i na ile jest skuteczne – tego niktspoza firmy nie wie.