Blokada dostępu do danych na procesorach Intela przełamana nowym atakiem Spectre

Grupa amerykańskich informatyków z Uniwersytetu Stanowego Ohio –profesorowie Yinqian Zhang, Zhiqiang Lin i Ten Lai, oraz ichdoktoranci Guoxing Chen, Sanchuan Chen i Yuan Xiao, przedstawili naGitHubie atak o nazwie SgxPectre. W towarzyszącym mu artykulept. SgxPectre Attacks: Leaking Enclave Secrets via SpeculativeExecution pokazują, że jeśli na przewidywanie rozgałęzieńkodu w enklawie wpłynie się za pomocą programów działającychpoza enklawą, to przepływ komend w enklawie może być czasowozmieniony tak, by wykonane zostały instrukcje prowadzące doobserwowalnych zmian w cache procesora. Napastnik obserwujący tezmiany może odczytać w ten sposób zawartość pamięci enklawy, anawet jej wewnętrznych rejestrów, co całkowicie kończy zpoufnością zgromadzonych danych.

Nie trzeba żadnych specjalnych uprawnień, wystarczy uruchomićkod exploitu na komputerze ofiary. Wówczas podobnie jak w wypadkustandardowego ataku Spectre, SgxPectre doprowadzi do nadużyciasytuacji hazardu pomiędzy wstrzykniętymi, spekulatywniewykonywanymi odniesieniami do pamięci oraz opóźnień wrozstrzyganiu rozgałęzień.

Napastnik zatruwa więc bufor rozgałęzień, wstrzykując doniego swoje adresy, przygotowuje procesor tak, aby zwiększyćprawdopodobieństwo uruchomienia instrukcji prowadzących do wyciekuinformacji z kodu działającego w enklawie, uruchamia kod w enklawie,a następnie monitoruje zachowanie cache procesora poprzez atakflush+reload.

Atak jest skuteczny zarówno przeciwko oprogramowaniu stworzonemuza pomocą oficjalnego Intel SGX SDK, jak i wykorzystującemubiblioteki Rust-SGX i Graphene-SGX. Co szczególnie istotne, czystosoftware’owe zabezpieczenie przeciwko Spectre, tj. zestaw łatekdla kompilatorów Retpoline, nie chroni przed SgxSpectre. Przezexploitem chronią jedynie łatki na poziomie mikrokodu,wprowadzające mechanizm IBRS (indirect branch restrictedspeculation) – czyści on całą historię przewidywaniarozgałęzień na granicach enklawy.

Sęk w tym, że kod działający w enklawie nie ma żadnegosposobu na ustalenie, czy działa na procesorze stosującym mikrokodz IBRS – a to czyni całe SGX Intela właściwie bezwartościowym.Celem mechanizmu było zabezpieczenie danych na niezaufanym sprzęcie,nad którym nie stosuje się kontroli – np. producent gry mógłbychcieć odszyfrowywać jej dane za pomocą klucza kryptograficznegoprzechowywanego w enklawie SGX.

Jak można się spodziewać, cracker pracujący nad złamaniemzabezpieczenia po prostu nie będzie na swojej maszynie instalowałmikrokodu Intela, uniemożliwiającego mu przełamanie zabezpieczeń.Tak samo jest w wypadku dostawców chmur – skąd mamy wiedzieć,jakie łatki zainstalowali na swoich serwerach? Można temu zapobiecjedynie każąc oprogramowaniu sprawdzić numer bezpieczeństwaprocesora (CPUSVN), odzwierciedla on zainstalowaną wersjęmikrokodu. Jeśli jest za mała, można zablokować dalszeuruchomienie programu. Napastnik jednak mógłby obejść takiesprawdzenie innym atakiem, a nawet sfałszować CPUSVN.

Jedynym sposobem na skuteczne zabezpieczenie się przed SgxSpectremogłoby by więc być przerobienie bibliotek korzystających z SGXtak, by usunąć z nich możliwe do wyexploitowania gadżety iutrudnić w ten sposób zatruwanie bufora rozgałęzień. Jest tojednak ekstremalnie trudne – i nie wiadomo, czy producencioprogramowania zdołają to zrobić.

Intel na razie nie zajął stanowiska w tej sprawie, mimo żeodkrywcy ujawnili to zagrożenie w sposób odpowiedzialny,kontaktując się z firmą przed opublikowaniem swojego artykułu.Już niebawem ma zostać udostępniony kod exploitu naopensource’owej licencji.