Odkrywcy luk w procesorach AMD twierdzą, że właśnie tak należy ujawniać zagrożenia

Ujawniając informacje o zagrożeniach, które otrzymały barwnenazwy RyzenFall, MasterKey, Fallout i Chimera, CTS Labs dało AMDniespełna 24 godziny na reakcję. W takim czasie nie sposóbporządnie przeczytać raportu, a co dopiero zbadać błędy,odtworzyć je i przygotować łatki. Nic więc dziwnego, żepubliczne udostępnienie stronyinternetowej i alarmującego filmiku na YouTube (z tłem wziętymze stockawideo) zostało uznane przez wielu za zwykłą kampanięoszczerstw. Podkreślano także, że opublikowany artykuł ozagrożeniach nie zawiera żadnych danych, pozwalającychzweryfikować ich wiarygodność, a sama firma to wydmuszka,która powstała wyłącznie po to, by zdyskredytować AMD,ewentualnie spekulować na spadkach wartości akcji producentaprocesorów.

Zapewne gdyby nie to, co stało się po tym, CTS Labs nieprzetrwałoby ataku w mediach społecznościowych. 13 marca odezwałsię jednak Dan Guido, szef firmy Trails of Bits, potwierdzającodkrycia izraelskich badaczy i informując, że jego firma jest wposiadaniu technicznego raportu oraz działających exploitów. Dzieńpóźniej do posiadania raportu przyznałsię niezależny ekspert Alex Ionescu. Stwierdził on, że całata medialna afera wokół okoliczności ujawnienia sprawy odwracauwagę od poważnej rozmowy o bezpieczeństwie.

Jak pamiętamy, niektórzy badacze ogłosili, że skoro zagrożeniewymaga dostępu administracyjnego, a nawet wgrania nieautoryzowanegofirmware, to nie jest żadnym zagrożeniem. Z perspektywy domowegoużytkownika mieli zapewne rację – ale czy tak samo jest tam,gdzie oferowane są podatne na ataki procesory EPYC, tj. w środowiskupublicznych chmur obliczeniowych? Ionescu wkrótce po tym odniósłsię i do tej kwestii, przypominającże dostęp z uprawnieniami administracyjnymi i możliwośćuzyskania trwałej obecności to poważne zagrożenia w rozwiązaniachtypu infrastruktura-jako-usługa (IaaS). Nie można też zlekceważyćtakich kwestii jak zaufanie do Credential Guard, gdy nie możemy ufaćczipsetowi i firmware.

Do tego dochodzi możliwość uzyskania przez malware stałej obecności w systemie: wpisanie złośliwego kodu w bezpieczne obszary procesora stawia go poza zasięgiem oprogramowania ochronnego. W ten sposób groźne ataki mogą stać się jeszcze groźniejsze, zauważa Ionescu.

Mimo wszystko CTS Labs pozostawało przyparte do muru. Dlaczego 24 godziny? Bardzo interesującej odpowiedzi udzielił w tej kwestii Ilia Luk-Zilberman, dyrektor techniczny izraelskiej firmy. W otwartym liście do całej branży wyjaśnia intencje, jakie stały za taką osobliwą formą ujawnienia.

Dla Luk-Zilbermana obecny standard ujawniania luk bezpieczeństwa to jakaś porażka. Jeśli badacz odkryje problem, to ma współpracować z producentem nad opracowaniem zabezpieczeń, dając jakiś określony termin (np. 90 dni), po którym luka zostaje publicznie ujawniona.

Dyrektor techniczny CTS Labs uważa jednak, że głównym problemem takiego podejścia jest to, że to od producenta zależy, czy zechce ostrzec swoich klientów – a zdarza się to niezwykle rzadko, by któryś powiedział zawczasu: mamy problemy, pracujemy nad ich rozwiązaniem. Niemal zawsze komunikat pojawia się post factum: mieliśmy problemy, oto łatka, nie ma czym się martwić. A co się stanie, jeśli producent nie zdąży w określonym czasie? Czy wtedy badacz ma ujawnić szczegóły luki, opublikować exploity, by wywrzeć presję na producencie? Narazić w konsekwencji klientów na ryzyko? Dla Luk-Zilbermana szokujące jest to, że przywykliśmy do ujawnianych przez badaczy exploitów, przez które cierpią zwykli użytkownicy, a nie producenci przecież.

Dlatego rozwiązaniem tej sytuacji miałby być zupełnie nowy model odpowiedzialnego ujawniania. Właśnie w takim modelu ujawnione zostały luki w procesorach AMD. W momencie odkrycia badacz informuje opinię publiczną i producenta, że istnieją w danym produkcie luki, przedstawia możliwe zagrożenia z nimi związane. Takie ujawnienie od początku wywiera presję na producenta, by luki załatał. Przykładowe exploity ani szczegółowa dokumentacja techniczna nie zostają publicznie ujawnione do momentu załatania luk, tak by nigdy, pod żadnym pozorem, nie narazić klientów na szwank.

Trzeba przyznać, że wytłumaczenie CTS Labs ma sens. Firma nie zamierza upubliczniać informacji o lukach w procesorach Ryzen, aby uniknąć sytuacji, w której odkrycia jej badaczy posłużą do ulepszenia malware, tworzonego czy to przez cyberprzestępców, czy pracujących dla mocarstw grup hakerskich.

Pod presją badaczy, twierdzących że te zagrożenia to jednak żadne zagrożenia, CTS Labs zdecydowało się opublikować dodatkowe wyjaśnienia w kwestii luk odkrytych w procesorach AMD. Widać z nich, że tak naprawdę jedyne co potrzeba, to uruchomienie exploitów z uprawnieniami administratora – a to jest do zrobienia. Nie dość, że wielu użytkowników Windowsa korzysta na co dzień z kont z takimi uprawnieniami, to przecież istnieje wiele ataków pozwalających na podwyższenie uprawnień. Zdalny atak jest więc jak najbardziej możliwy, a po nim mamy malware siedzące w miejscu, którego żaden antywirus nie dotknie.

Z naszej strony możemy powiedzieć tylko tyle, że już jakiś czas temu inżynierowie Google pracujący nad środowiskiem Coreboot, analizując zagrożenia tkwiące w Intel Management Engine, ostrzegli, aby za bardzo nie cieszyć się na na AMD. Nie wierzcie we wszystko, co przeczytaliście o Ryzenie – ostrzegali, radząc by ufać tylko minimalnemu firmware na bazie Linuksa. A kilka miesięcy później zespół bezpieczeństwa Google odkrył pierwszą lukę w Platform Security Processor czipów Ryzen.

Możemy mieć tylko nadzieję, że jeśli w kolejnej dekadzie pojawią się otwarte, wydajne, konkurencyjne względem x86 architektury procesorowe, takie jak RISC-V, to w budowanych na ich bazie procesorach nie będzie takich wynalazków jak PSP czy IME. Naprawdę producenci, dajcie użytkownikom wybór – wielu z nas wcale nie chce w swoim sprzęcie tajemniczych układów, które robią nie wiadomo co poza kontrolą normalnego systemu operacyjnego. Używajcie tego wyłącznie w procesorach dla biznesu, jeśli to naprawdę konieczne dla zdalnego zarządzania, ale oszczędźcie zwykłym użytkownikom tego złudnego sprzętowego bezpieczeństwa, które jak widać przynosi same kłopoty.