Kees Cook, un fost șef administrator la kernel.org și lider al echipei de securitate Ubuntu, care lucrează acum la Google pentru a proteja Android și ChromeOS, a lansat un set de patch-uri care aleatorizează compensările stivei de kernel la gestionarea apelurilor de sistem. Patch-urile îmbunătățesc securitatea kernelului prin schimbarea locației stivei, lsau asta face ca atacurile de tip stack să fie mult mai dificile și mai puțin reușite
Ideea originală pentru patch aparține proiectului PaX RANDKSTACK. În 2019, Elena Reshetova, inginer la Intel, a încercat să creeze o implementare a acestei idei, potrivită pentru includerea în compoziția principală a nucleului Linux.
Ulterior, inițiativa a fost luată de Kees Cook care a prezentat o implementare adecvată pentru versiunea principală a nucleului și ale cărei patch-uri sunt planificate pentru versiunea 5.13 a Linux.
Modul va fi dezactivat în mod implicit și, pentru a-l activa, este oferit parametrul liniei de comandă a nucleului "Randomize_kstack_offset = on / off»Și setări CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT, În plus, cheltuielile generale pentru activarea modului sunt estimate la aproximativ 1% pierderi de performanță.
Esența protecției propuse este alegerea unui offset aleatoriu de stivă la fiecare apel de sistem, ceea ce complică determinarea aspectului stivei în memorie, chiar dacă sunt primite informații despre adresă, deoarece adresa de bază a stivei se va schimba la următorul apel.
Spre deosebire de implementarea PaX RANKSTACK, în patch-urile propuse pentru includerea în nucleu, randomizarea nu se face în etapa inițială, dar după setarea structurii pt_regs, ceea ce face imposibilă utilizarea metodelor bazate pe ptrace pentru a determina un offset aleatoriu în timpul unui apel sistem de lungă durată.
Pe măsură ce protecția stivei kernel-ului Linux s-a îmbunătățit în mod constant (cartografierea stivei bazată pe vmap cu pagini de protecție, eliminarea thread_info, STACKLEAK), atacatorii au fost nevoiți să găsească noi modalități prin care exploatările lor să funcționeze.
Ei au și continuă să se bazeze pe determinismul stivei de nuclee, în situații în care VMAP_STACK și THREAD_INFO_IN_TASK_STRUCT nu erau relevante. De exemplu, următoarele atacuri recente ar fi fost îngreunate dacă offset-ul stivei nu era determinist între apelurile de sistem
Scopul funcției randomize_kstack_offset este de a adăuga un offset aleatoriu după ce pt_regs a fost împins pe stivă și înainte ca restul stivei de fire să fie utilizat în timpul procesării apelurilor de sistem și să-l schimbe de fiecare dată când un proces emite un apel de sistem. Sursa aleatoriei este definită în prezent de arhitectură (dar x86 folosește octetul scăzut al rdtsc ()).
Îmbunătățirile viitoare sunt posibile pentru diferite surse de entropie, dar în afara scopului acestui patch. De asemenea, pentru a adăuga mai multă imprevizibilitate, se aleg noi compensări la sfârșitul apelurilor de sistem (al căror timp ar trebui să fie mai puțin ușor de măsurat din spațiul utilizatorului decât la momentul intrării apelului de sistem) și sunt stocate într-o singură variabilă pe CPU, astfel încât durata de viață a valorii să nu rămână legată în mod explicit de o singură sarcină.
Nu există modificări vizibile pentru acest lucru pe x86, deoarece economizorul de stivă este deja dezactivat necondiționat pentru unitatea de compilare, dar schimbarea este necesară în arm64. Din păcate, nu există nici un atribut care să poată fi folosit pentru a dezactiva economisirea stivei pentru funcții specifice. Comparație cu funcția PaX RANDKSTACK: Funcția RANDKSTACK randomizează locația startului stivei (cpu_current_top_of_stack), adică include locația structurii pt_regs pe stivă.
inițial, acest patch a urmat aceeași abordare, dar în timpul discuțiilor recente s-a stabilit că este de mică valoare, ca și cum funcționalitatea ptrace este disponibilă pentru un atacator, puteți utiliza PTRACE_PEEKUSR pentru a citi / scrie diferite compensări în structura pt_regs, pentru a observa comportamentul cache al acceselor pt_regs și pentru a afla compensarea stivei aleatorii.
În cele din urmă se menționează că implementarea inițială acceptă procesoarele ARM64 și x86 / x86_64.