Kees Cook, były główny sysadmin w kernel.org i lider zespołu ds. bezpieczeństwa Ubuntu, obecnie pracującego w Google nad ochroną Androida i ChromeOS, wydał zestaw łat, które losują przesunięcia stosu jądra podczas obsługi wywołań systemowych. Poprawki poprawiają bezpieczeństwo jądra, zmieniając położenie stosu, llub to sprawia, że ataki na stosy są znacznie trudniejsze i mniej skuteczne
Oryginalny pomysł na łatkę należy do projektu PaX RANDKSTACK. W 2019 roku Elena Reshetova, inżynier Intela, próbowała stworzyć implementację tego pomysłu, nadającą się do włączenia do głównego składu jądra Linuksa.
Następnie inicjatywę przejął Kees Cook który przedstawił odpowiednią implementację dla głównej wersji jądra i którego poprawki są planowane dla wersji 5.13 Linuksa.
Tryb będzie domyślnie wyłączony, a aby go włączyć, oferowany jest parametr wiersza poleceń jądra "Randomize_kstack_offset = on / off»I ustawienia CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT, Ponadto narzut związany z włączaniem trybu szacowany jest na około 1% utraty wydajności.
Istotą proponowanej ochrony jest wybranie losowego przesunięcia stosu przy każdym wywołaniu systemowym, co komplikuje określenie układu stosu w pamięci, nawet jeśli odebrane zostaną informacje adresowe, ponieważ adres bazowy stosu zmieni się przy następnym wywołaniu.
W przeciwieństwie do implementacji PaX RANKSTACK, w łatach proponowanych do włączenia do jądra, randomizacja nie jest wykonywana na początkowym etapie, ale po ustawieniu struktury pt_regs, co uniemożliwia użycie metod opartych na ptrace do określenia losowego przesunięcia podczas długotrwałego wywołania systemowego.
Ponieważ zabezpieczenia stosu jądra Linuksa były stale ulepszane (mapowanie stosu oparte na vmap ze stronami ochrony, usuwanie thread_info, STACKLEAK), atakujący musieli znaleźć nowe sposoby działania swoich exploitów.
Mają i nadal polegają na determinizmie stosu jądra w sytuacjach, w których VMAP_STACK i THREAD_INFO_IN_TASK_STRUCT nie były istotne. Na przykład następujące niedawne ataki zostałyby utrudnione, gdyby przesunięcie stosu nie było deterministyczne między wywołaniami systemowymi
Celem funkcji randomize_kstack_offset jest dodanie losowego przesunięcia po umieszczeniu pt_regs na stosie i zanim reszta stosu wątków zostanie użyta podczas przetwarzania wywołania systemowego, i zmieniaj go za każdym razem, gdy proces wysyła wywołanie systemowe. Źródło losowości jest obecnie definiowane przez architekturę (ale x86 używa młodszego bajtu rdtsc ()).
Przyszłe ulepszenia są możliwe dla różnych źródeł entropii, ale poza zakresem tej poprawki. Ponadto, aby dodać więcej nieprzewidywalności, nowe przesunięcia są wybierane na końcu wywołań systemowych (których czas powinien być trudniejszy do zmierzenia z przestrzeni użytkownika niż w momencie wejścia wywołania systemowego) i są one przechowywane w jednej zmiennej na CPU, dzięki czemu okres istnienia wartości nie pozostaje jawnie powiązany z pojedynczym zadaniem.
Nie ma widocznych zmian dla tego na x86, ponieważ oszczędzanie stosu jest już bezwarunkowo wyłączone dla jednostki kompilującej, ale zmiana jest wymagana w arm64. Niestety, nie ma atrybutu, którego można użyć do wyłączenia oszczędzania stosu dla określonych funkcji. Porównanie z funkcją PaX RANDKSTACK: Funkcja RANDKSTACK losuje położenie początku stosu (cpu_current_top_of_stack), to znaczy zawiera lokalizację struktury pt_regs na stosie.
Początkowo, w tym patchu zastosowano to samo podejście, ale podczas ostatnich dyskusji ustalono, że ma on niewielką wartość, ponieważ jeśli funkcja ptrace jest dostępna dla atakującego, można użyć PTRACE_PEEKUSR do odczytu / zapisu różnych przesunięć do struktury pt_regs, obserwowania zachowania pamięci podręcznej dostępu do pt_regs i losowe przesunięcie stosu.
Wreszcie jest o tym mowa początkowa implementacja obsługuje procesory ARM64 i x86 / x86_64.