Wszystkie systemy z groźnym błędem. Przyczyną niezrozumienie słów Intela

Amerykański CERT, przedstawiając tę lukę oznaczoną jakoCVE-2018-8897,wskazuje od razu na jej genezę: podręcznik System Programming Guidedla 32- i 64-bitowych architektur Intela. Jedno zdanie doprowadziłodo tego, że producenci oprogramowania źle zrozumieli to, jakprocesory Intela (i kompatybilne z nimi procesory AMD) obsługująjedno wywołanie.

Zainteresowanych zapoznaniem się z tym nieporozumieniem w całejrozciągłości technicznych szczegółów zapraszamy do artykułuPOP SS/MOV SS Vulnerability, autorstwa Nicka Petersona iNemanji Mulasmajica, odkrywców tego przeoczenia. Pozostałymprzedstawimy problem w pewnym uproszczeniu.

Na liście instrukcji x86 znajdziemy POPSS. Ładuje ona z wierzchu stosu uruchomionego programu wartośćużytą do wybrania segmentu stosu, do rejestru SS (selektor stosu),wskazującego na obecny segment stosu. Następnie zwiększa zaś ojeden wskaźnik stosu. Po co ta instrukcja? Cóż, to pokłosiesegmentacji pamięci w architekturze x86, dzięki której możliwebyło zaadresowanie więcej niż 64 KB RAM. W dzisiejszych systemachoperacyjnych to bez znaczenia, ale POP SS pozostało. Ważne jest to,że POP SS jest specjalnie obsługiwane przez procesor, tak że nawetwywołanie w trakcie jego wykonywania przerwania nie może pozostaćw niespójnym stanie.

Z tego co piszą Peterson i Mulasmajic wynika, że aplikacja możeustawić pułapkę (breakpoint) dla tej lokacji pamięci, z którejwartość selektora stosu zostanie wyciągnięta przez POP SS. Kiedyzaś aplikacja wywoła już POP SS, procesor dotykając tej częścipamięci wywoła specjalny wyjątek. Dla uproszczenia pomijamy tutajinstrukcję MOV SS, wystarczy wiedzieć, że ona także może zostaćwykorzystana do takiego ataku.

Teraz spójrzmy na instrukcję INT (ewentualnie SYSCALL, ale dlauproszczenia to też pominiemy). INT służy do wywołania dowolnegoprzerwania software’owego. Jeśli po POP SS umieścimy INT, mamysytuację w której wygenerowany jest wyjątek, a zarazem systemwywołuje przerwanie. Wywołanie przerwania na procesorach Intela iAMD zmusza je do wejścia w uchwyt przerwań kernela. Ale zaraz,właśnie w tym momencie uruchamia się pułapka, ponieważnajwyraźniej POP SS opóźnia jej wykonanie w czasie.

Czegoś takiego po prostu być nie może. Projektanci systemówoperacyjnych naczytali się podręczników Intela i wyszli zzałożenia, że uchwyt przerwań startuje w czystym stanie.Tymczasem już na samym początku ma sobie poradzić zniespodziewanym wyjątkiem z pułapki. Prowadzi to do nieoczekiwanejsytuacji, w której kernel gotowy jest przyjąć dane wskazane muprzez działające w trybie użytkownika oprogramowanie.

Z artykułu możemy się dowiedzieć, że na Intelu exploit polegana połączeniu instrukcji POP SS i INT, po których kontrolowaćwskaźnik GSBASE w uchwycie przerwań. Z kolei w AMD aplikacja możekontrolować zarówno GSBASE jak i wskaźnik stosu. W obu wypadkachnajczęściej doprowadzi to do kompletnej awarii kernela, aleodpowiednio precyzyjnie sterując zachowaniem procesora, możnawydobyć też informacje z pamięci chronionej, a nawet przejąćkontrolę nad kolejnością wykonywania rozkazów i w konsekwencjiuruchomić własny kod.

#Intel released the 67th edition of the Software Developer’s Manuals with interrupt related modifications https://t.co/qh7jNcQQFN pic.twitter.com/XZ6nkHrITV

— InstLatX64 (@InstLatX64) May 8, 2018Na czym dzisiaj stoimy? No cóż, branża naprawiła wszystko, cosię dało naprawić. Microsoft załatał tę podatność w swoichwtorkowychłatkach. Apple zrobiło to w łatce Security Update 2018-001z kwietnia. Swoją robotę odrobili też producenci kluczowychlinuksowych dystrybucji: Ubuntui RHEL-a.Naprawiono też kernel FreeBSDoraz hiperwizor Xen,łatki dla swoich urządzeń wydało też Synology.

Najważniejsze zaś, że Intel poprawił swoją dokumentację. 8maja opublikowanozaktualizowane Intel® 64 and IA-32 Architectures Software DeveloperManuals w wersji 067. Niebiescy zapewniają, że już właściwiewyjaśniono w nich wszystkie kwestie związane z przerwaniami.