Kees Cook, bivši glavni sysadmin na kernel.org i vođa Ubuntu sigurnosnog tima, koji sada radi u Googleu kako bi zaštitio Android i ChromeOS, je objavio set zakrpa koje randomiziraju pomake stoga jezgre prilikom rukovanja sistemskim pozivima. Zakrpe poboljšavaju sigurnost jezgre promjenom mjesta steka, lili to čini stack napade puno težim i manje uspješnim
Izvorna ideja za flaster pripada projektu PaX RANDKSTACK. Godine 2019. Elena Reshetova, Intelova inženjerka, pokušala je stvoriti provedbu ove ideje, prikladne za uključivanje u glavni sastav Linux jezgre.
Naknadno je inicijativu preuzeo Kees Cook koji je predstavio prikladnu implementaciju za glavnu verziju jezgre i čije su zakrpe planirane za verziju 5.13 Linuxa.
Način će biti onemogućen prema zadanim postavkama i da bi se omogućio, nudi se parametar retka naredbe jezgre "Randomize_kstack_offset = uključeno / isključeno»I postavke CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT, Uz to, općeniti troškovi omogućavanja načina rada procjenjuju se na približno 1% gubitka performansi.
Bit predložene zaštite je odabir slučajnog odmaka sloga za svaki sistemski poziv, što komplicira određivanje izgleda steka u memoriji čak i ako su primljene informacije o adresi, jer će se osnovna adresa stoga promijeniti tijekom sljedećeg poziva.
Za razliku od provedbe PaX RANDK STACK, u zakrpama predloženim za uključivanje u jezgru, randomizacija se ne vrši u početnoj fazi, ali nakon postavljanja strukture pt_regs, što onemogućuje upotrebu metoda temeljenih na ptraceu za određivanje slučajnog odstupanja tijekom dugotrajnog sistemskog poziva.
Kako su se zaštite Linux stack kernela neprestano poboljšavale (mapiranje steka temeljeno na vmap-u sa stranicama zaštite, uklanjanje thread_info-a, STACKLEAK), napadači su morali pronaći nove načine za rad svojih exploita.
Oni imaju i nastavljaju se oslanjati na determinizam stoga jezgre, u situacijama kada VMAP_STACK i THREAD_INFO_IN_TASK_STRUCT nisu bili relevantni. Na primjer, sljedeći nedavni napadi bili bi ometeni da pomak steka nije bio deterministički između sistemskih poziva
Svrha funkcije randomize_kstack_offset je dodati slučajni pomak nakon što je pt_regs gurnut na stog i prije nego što se ostatak niza niti koristi tijekom obrade sistemskog poziva, i promijenite ga svaki put kad proces izda sistemski poziv. Izvor slučajnosti trenutno je definiran u arhitekturi (ali x86 koristi mali bajt rdtsc ()).
Buduća poboljšanja moguća su za različite izvore entropije, ali izvan opsega ove zakrpe. Također, da bi se dodala veća nepredvidljivost, na kraju sistemskih poziva biraju se novi pomaci (čije bi vrijeme trebalo biti manje lako izmjeriti iz korisničkog prostora nego u trenutku ulaska u sistemski poziv) i pohranjuju se u jednu varijablu po CPU, tako da vijek trajanja vrijednosti ne ostaje izričito vezan za jedan zadatak.
Nema vidljivih promjena za ovo na x86, jer je čuvar steka već bezuvjetno onemogućen za jedinicu kompilacije, ali promjena je potrebna u arm64. Nažalost, ne postoji atribut koji se može koristiti za onemogućavanje štediša steka za određene funkcije. Usporedba s funkcijom PaX RANDKSTACK: Funkcija RANDKSTACK randomizira mjesto početka steka (cpu_current_top_of_stack), odnosno uključuje mjesto strukture pt_regs na stogu.
U početku, ovaj flaster slijedio je isti pristup, ali tijekom nedavnih rasprava utvrđeno je da ima malu vrijednost jer je funkcionalnost ptracea dostupna napadaču, možete koristiti PTRACE_PEEKUSR za čitanje / pisanje različitih odstupanja u strukturu pt_regs, promatranje ponašanja predmemorije pristupa pt_regs i otkrivanje slučajni pomak sloga.
Napokon se spominje da početna implementacija podržava ARM64 i x86 / x86_64 procesore.