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

Strona główna Aktualności

O autorze

W procesorach Core 6. generacji – Skylake – Intel zastosował innowacyjny mechanizm zabezpieczeń o nazwie SGX, Software Guard Extensions. Pozwalał on oprogramowaniu działającemu z uprawnieniami użytkownika na zadeklarowanie prywatnych obszarów pamięci, tzw. enklaw, które chronione były nawet przed procesami działającymi z wyższymi uprawnieniami. SGX miało przynieść odporne na złamanie mechanizmy DRM, bezpieczne przetwarzanie danych w przeglądarkach i zdalnie uruchamiane maszyny wirtualne, do których pamięci dostawca chmury obliczeniowej nie miałby dostępu. Brzmi wspaniale, ale niekoniecznie jest tak samo skuteczne. Okazuje się, że ujawniony na początku tego roku atak Spectre pozwala przełamać zabezpieczenia SGX.

Grupa amerykańskich informatyków z Uniwersytetu Stanowego Ohio – profesorowie Yinqian Zhang, Zhiqiang Lin i Ten Lai, oraz ich doktoranci Guoxing Chen, Sanchuan Chen i Yuan Xiao, przedstawili na GitHubie atak o nazwie SgxPectre. W towarzyszącym mu artykule pt. SgxPectre Attacks: Leaking Enclave Secrets via Speculative Execution pokazują, że jeśli na przewidywanie rozgałęzień kodu w enklawie wpłynie się za pomocą programów działających poza enklawą, to przepływ komend w enklawie może być czasowo zmieniony tak, by wykonane zostały instrukcje prowadzące do obserwowalnych zmian w cache procesora. Napastnik obserwujący te zmiany może odczytać w ten sposób zawartość pamięci enklawy, a nawet jej wewnętrznych rejestrów, co całkowicie kończy z poufnością zgromadzonych danych.

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

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

Atak jest skuteczny zarówno przeciwko oprogramowaniu stworzonemu za pomocą oficjalnego Intel SGX SDK, jak i wykorzystującemu biblioteki Rust-SGX i Graphene-SGX. Co szczególnie istotne, czysto software’owe zabezpieczenie przeciwko Spectre, tj. zestaw łatek dla kompilatorów Retpoline, nie chroni przed SgxSpectre. Przez exploitem chronią jedynie łatki na poziomie mikrokodu, wprowadzające mechanizm IBRS (indirect branch restricted speculation) – czyści on całą historię przewidywania rozgałęzień na granicach enklawy.

Sęk w tym, że kod działający w enklawie nie ma żadnego sposobu na ustalenie, czy działa na procesorze stosującym mikrokod z 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łby chcieć odszyfrowywać jej dane za pomocą klucza kryptograficznego przechowywanego w enklawie SGX.

Jak można się spodziewać, cracker pracujący nad złamaniem zabezpieczenia 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 zapobiec jedynie każąc oprogramowaniu sprawdzić numer bezpieczeństwa procesora (CPUSVN), odzwierciedla on zainstalowaną wersję mikrokodu. Jeśli jest za mała, można zablokować dalsze uruchomienie programu. Napastnik jednak mógłby obejść takie sprawdzenie innym atakiem, a nawet sfałszować CPUSVN.

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

Intel na razie nie zajął stanowiska w tej sprawie, mimo że odkrywcy 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 na opensource’owej licencji.

© dobreprogramy