Intel/AMD/ARM – wszystko podatne (Meltdown & Spectre) – wykradanie pamięci z OS

FAQ: 1. Czy jestem podatny? Najprawdopodobniej tak.
To tłumaczenie pierwszego często zadawanego pytania dotyczącego podatności Meltdown & Spectre.

Do sprawy przygotowali się panowie z Google, zgodnie z założeniami – „pokaż exploit to ci uwierzę”. Zatem na start pokazano PoC-e (podatność Spectre) na procesory: Intel Haswell Xeon CPU, the AMD FX CPU, AMD PRO CPU, ARM Cortex A57.

Przykładowo:

(…) normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range in kernel virtual memory on the Intel Haswell Xeon CPU (…) kernel virtual memory can be read at a rate of around 2000 bytes per second.

Odczytywanie pamięci jądra z prędkością 2000 bajtów na sekundę może nie jest super optymalne, ale zobaczcie że można  wyciągnąć sporo (powyższy PoC – okno 4 GB pamięci).

W boju (przechodzimy teraz do Meltdown – czyli problem potwierdzony na Intelu i części ARM-ów) wygląda to mniej więcej tak jak na zrzucie poniżej (w tyle pamięć jądra – w dużym uproszczeniu pamięć OS) + w osobnym oknie odpalony exploit wykradający konkretny adres pamięci. Można też całość zobaczyć na poglądowym filmie.

Bum.

Inny ciekawy PoC to wykradanie haseł z password managera w innej instancji Firefoksa (zarówno FF jak i Ubuntu w zaktualizowanych wersjach):

Password Manager

I hasła w plaintext:

Hasła

Kolejny PoC został zaprezentowany dla wirtualizacji (wracamy na moment do Spectre) – wykradanie pamięci z pamięci głównej maszyny (host), posiadając dostęp tylko do guesta – nie brzmi dobrze (operatorzy cloudowi obgryzają w tym momencie paznokcie).

Prędkość odczytu to około 1500 bajtów na sekundę. Tutaj jednak Google przyznaje, że do testów użyło nieco już przestarzałej dystrybucji Debiana (operatorzy cloudowi przestają obgryzać paznokcie, szczególnie że tutaj  można znaleźć informacje, że pełna wirtualizacja nie powinna być zagrożona – problematyczna jest parawirtualizacja zapewniania np. przez XEN czy Dockera).

W oryginalnej publikacji (Meltdown) wykonano testy na cloudach DigitalOcean i Amazona, gdzie raczej będą „świeże” dystrybucje Linuksa:

For the cloud setup, we tested Meltdown in virtual machines running on Intel Xeon CPUs hosted in the Amazon Elastic Compute Cloud as well as on DigitalOcean. Note that for ethical reasons we did not use Meltdown on addresses referring to physical memory of other tenants.

W cytowanej pracy jest mowa o całkiem niezłej prędkości wycieku danych dla testów właśnie w cloudzie (do 503KB/s)

Meltdown & Spectre

Czym w zasadzie różnią się te dwie podatności? W skrócie prowadzą do tego samego – odczyt pamięci, do której nie powinienem mieć dostępu. Meltdown umożliwia czytanie pamięci z OS, Spectre umożliwia odczyt pamięci pomiędzy aplikacjami.

Gadu gadu, ale jaka jest w zasadzie istota podatności Meltdown? Taka:

Meltdown is some form of race condition between the fetch of a memory address and the corresponding permission check for this address.

Owy race condition, z kolei bazuje na dużej optymalizacji w procesorach zwanej out-of-order execution. Zacytujmy większy fragment:

The root cause of the simplicity and strength of Meltdown are side effects caused by out-of-order execution. Out-of-order execution is an important performance feature of today’s processors in order to overcome latencies of busy execution units, e.g., a memory fetch unit needs to wait for data arrival from memory. Instead of stalling the execution, modern processors run operations out-of-order i.e., they look ahead and schedule subsequent operations to idle execution units of the processor.

Polecamy zresztą zapoznanie się z oryginalną publikacją – szczególnie pierwsze dwa rozdziały napisane są bardzo przystępnie.

Patche

Patche nie są jeszcze wszędzie dostępne (albo są wydawane w pośpiechu rodząc potencjalnie inne problemy). O samym Spectre zresztą możemy poczytać:

As it is not easy to fix, it will haunt us for quite some time.

–ms