Zapis do pamięci jądra: niechlujstwo twórców Windows wychodzi na jaw

Systemy operacyjne są systemami dlatego, ze poza zarządzaniem zadaniami dostarczają podstawowe wywołania programistyczne. Są nazywane wywołaniami systemowymi (syscalls) i dostarczają funkcji fundamentalnych, leżących poniżej środowiska uruchomieniowego. Do operacji realizowanych przez wywołania systemowe należą na przykład tworzenie i rozwidlanie procesów, otwieranie uchwytów plikowych, zapis strumieni bajtów itd. Każdy system zawiera spory ich zbiór.

Choć istnieje pewien niepodważalny kanon i np. zbiór funkcji POSIX jest wszędzie taki sam, a /usr/include/x86_64-linux-gnu/sys dostarcza mniej więcej tyle samo, liczba wywołań systemowych rośnie. Wynika to między innymi ze wzrostu złożoności sprzętu, na którym uruchamiane są nowe systemy operacyjne. Przykładem takiej nowej złożoności jest mechanizm Intel SGX: pozwala on tworzyć tzw. bezpieczne enklawy: obszary pamięci, które nie mogą być czytane przez kod spoza enklawy.

Istnieje, oczywiście, ochrona pamięci. Nie da się swobodnie czytać cudzej pamięci z innego procesu. Diabeł tkwi jednak w tym "swobodnie": nie jest możliwe odwoływanie się bezpośrednio do pamięci, ale można (a raczej trzeba) się odwoływać pośrednio. Nie można domyślnie czytać pamięci innych procesów, ale można o to po prostu poprosić. Nadać procesowi prawa do czytania jego pamięci, a następnie sięgać do niej z innego procesu.

To groźne, ale niekoniecznie bezpośrednio łatwe do wykorzystania. Cudzą pamięć trzeba wtedy czytać na oślep, a to utrudnia skuteczne "włamanie z kradzieżą". O wiele łatwiej jest kraść dane zapisane ("data at rest"). Nie da się też czytać pamięci usług i innych użytkowników (no, chyba że pracuje się z domyślnym UAC...), system na to nie pozwoli. Z powyższych stwierdzeń można wysnuć następujące wnioski: wywołania systemowe muszą być bezpieczne, bo to od nich zależy poziom bezpieczeństwa całego systemu. A po drugie, słynna "ochrona pamięci" daje tak naprawdę bardzo mało.

Wróćmy teraz do wspomnianego wcześniej SGX: zapewnia on ochronę pamięci o najwyższym poziomie granularyzacji: tylko kod leżący w enklawie może czytać dane z enklawy (ale może czytać też dane spoza niej), a kod leżący poza nią, nie ma do niej dostępu. Sprzętowo. Nie ma znaczenia bycie administratorem ani nadanie praw PROCESS_VM_READ. Nie pomoże nawet ścieżka wykonania w ramach tego samego wątku (który przecież "ma wspólną pamięć"). Po prostu nie da się i tyle. Takie cuda umie dopiero procesor Skylake i nowsze (Pavel Yosifovich, Solomon, Ionescu), a odpowienie API w postaci wywołań systemowych NtCreateEnclave dostarcza dopiero Windows 10 1511 i nowsze.

Wcześniejsze systemy po prostu nie istniały w czasie, gdy na rynku istniał jakikolwiek procesor, który umiałby obsługiwać enklawy. Oznacza to, że LPVOID CreateEnclave() powstało w czasach (i z okazji) głębokiej świadomości ryzyka nieostrożnej alokacji pamięci, przerobienia wielu setek błędów *null pointer dereference, od których lądowało się w krzakach i znając skalę problemów ze sprzętowym bezpieczeństwem. Okazuje się jednak, że to nie wystarcza. Walied Assar odkrył, że NtCreateEnclave istotnie tworzy "bezpieczną enklawę", ale najwyraźniej pozwala ją założyć wszędzie. Podanie odpowiedniego argumentu lpAddress umożliwia nałożenie obszaru enklawy na obszar jądra i pisanie po nim. Taka enklawa jest zapewne wadliwa, ale odczyt – skuteczny.Problemy rodem z ubiegłego mileniumW trafny sposób do tematu odniósł się Alex Ionescu, ceniony specjalista do spraw zabezpieczeń Windows. Według niego, błędy takiego rodzaju powinny być już nieobecne w oprogramowaniu tworzonym w czasach znajomości groźnych praktyk. Ponadto, opisywana funkcja ma inne, znane błędy, choć dotyczy mechanizmu bezpieczeństwa. Wreszcie, błąd tego rodzaju jest łatwy do wykrycia przez fuzzer: narzędzie automatycznie generujące śmieci jako wejścia funkcji, celem sprawdzenia na ślepo, czy da się ją zmusić do niecnych zachowań. Stanowi to typową metodę testowania nowych środków zabezpieczeń i tutaj jej zabrakło.