Lansarea modulului LKRG 0.8 pentru protecția împotriva exploatării vulnerabilităților în nucleul Linux

Proiectul Openwall a publicat lansarea modulului kernel LKRG 0.8 (Linux Kernel Runtime Guard), destinat detectării și blocării atacurilor și încălcărilor integrității structurilor kernel. De exemplu, modulul poate proteja împotriva modificărilor neautorizate în nucleul activ și a încercărilor de a schimba privilegiile proceselor utilizator (definirea exploatării). Modulul este potrivit atât pentru organizarea protecției împotriva exploatărilor deja cunoscute pentru kernelul Linux (de exemplu, în situațiile în care este problematic să se actualizeze kernelul în sistem), cât și pentru a face față exploatărilor pentru vulnerabilități încă necunoscute. Codul proiectului se răspândește sub licența GPLv2.

Printre modificările din noua versiune:

• A fost modificată poziționarea proiectului LKRG, care acum nu mai este împărțit în subsisteme separate pentru verificarea integrității și determinarea exploatărilor, ci este prezentat ca un produs unitar pentru identificarea atacurilor și diferitelor încălcări ale integrității;
• A fost asigurată compatibilitatea cu kernelurile Linux între versiunile 5.3 și 5.7, precum și cu kernelurile compilate cu optimizări agresive GCC, fără opțiunile CONFIG_USB și CONFIG_STACKTRACE sau cu opțiunea CONFIG_UNWINDER_ORC, dar și cu kernelurile care nu conțin funcții LKRG interceptabile, atunci când se poate renunța la acestea;
• La compilare, s-a asigurat verificarea unor setări obligatorii CONFIG_* pentru a genera mesaje de eroare semnificative în locul eșecurilor neclare;
• A fost adăugată suportul pentru modurile de așteptare (ACPI S3, suspendare în RAM) și modurile de repaus (S4, suspendare pe disc);
• În Makefile a fost adăugată suport pentru DKMS;
• A fost implementat suport experimental pentru platformele ARM pe 32 de biți (testat pe Raspberry Pi 3 Model B). Suportul anterior disponibil pentru AArch64 (ARM64) a fost completat prin asigurarea compatibilității cu placa Raspberry Pi 4;
• Au fost adăugați noi handleri (hook), inclusiv handlerul apelului capable() pentru a determina mai bine exploatările care manipulează „capabilities„, mai degrabă decât identificatorii proceselor (credentails);
• A fost propusă o nouă logică pentru determinarea încercărilor de ieșire din limitele spațiilor de nume (de exemplu, din containerele Docker);
• Pe sistemele x86-64, s-a asigurat verificarea și aplicarea bitului SMAP (Supervisor Mode Access Prevention), destinat blocării accesului la date în spațiul utilizatorului din codul privilegiat care rulează la nivelul kernelului. Protecția SMEP (Supervisor Mode Execution Prevention) a fost implementată anterior;
• În timpul execuției, s-au asigurat plasarea setărilor LKRG în pagina de memorie, de obicei accesibilă doar pentru citire;
• Ieșirea în loguri a informațiilor care pot fi cele mai utile pentru atacuri (de exemplu, informații despre adrese în nucleu) este limitată la modul de depanare (log_level=4 și mai sus), dezactivat în mod implicit.
• Scalabilitatea bazei de date pentru urmărirea proceselor a fost îmbunătățită — în loc de un singur arbore RB, protejat de un singur spinlock, este utilizată o tabelă de hash din 512 arbori RB, protejați corespunzător de 512 blocări de citire-scriere;
• A fost implementat și activat implicit un mod în care verificarea integrității identificatorilor de proces se efectuează frecvent doar pentru sarcina curentă, precum și opțional pentru sarcinile activate (care se trezesc). Pentru celelalte sarcini, aflate în stare de somn sau care funcționează fără a apela la API-ul LKRG din nucleu, verificarea se efectuează mai rar.
• Au fost adăugate noi sysctl și parametrii modulului pentru ajustarea fină a LKRG, precum și două sysctl pentru configurarea simplificată prin alegerea dintre seturi de configurări fine pregătite de dezvoltatori (profiles);
• Setările implicite au fost modificate pentru a obține un echilibru mai bine cântărit între rapiditatea detectării încălcărilor și eficacitatea reacției, pe de o parte, și impactul asupra performanței și riscul de alarme false, pe de altă parte;
• Fișierul unitate systemd a fost reproiectat pentru a încărca modulul LKRG într-o etapă timpurie a încărcării (pentru a dezactiva modulul poate fi folosit parametrul din linia de comandă a nucleului);

Având în vedere optimizările propuse în noua versiune, reducerea performanței atunci când se utilizează LKRG 0.8 este estimată la 2.5% în modul implicit („heavy”) și 2% în modul ușor („light”).

Într-un studiu recent cercetare eficienței pachetelor pentru detectarea rootkit-urilor LKRG a arătat cele mai bune rezultate, fără alarme false, identificând 8 din 9 rootkit-uri testate, care operează la nivel de nucleu (au fost detectate rootkit-urile Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit și Sutekh, dar a fost ratat Keysniffer, care este un modul de nucleu cu un keylogger, nu un rootkit în sensul direct). Spre comparație, pachetele AIDE, OSSEC și Rootkit Hunter au detectat 2 rootkit-uri din 9, iar Chkrootkit nu a identificat niciunul. În același timp, LKRG nu suportă detectarea rootkit-urilor plasate în spațiul utilizatorului, prin urmare, cea mai mare eficiență este atinsă prin utilizarea combinării AIDE și LKRG, care a permis identificarea a 14 din 15 rootkit-uri de toate tipurile.

De asemenea, merită menționat că dezvoltatorul distribuției Whonix a început formarea are pachete DKMS pregătite pentru Debian, Whonix, Qubes și Kicksecure, iar pachetul pentru Arch Linux a fost deja actualizat la versiunea 0.8. Pachetele cu LKRG sunt de asemenea disponibile în Rusia. ALT Linux și Astra Linux.

Verificarea integrității în LKRG se bazează pe compararea codului și datelor curente ale nucleului și modulelor, a unor structuri de date importante și a configurațiilor CPU cu hash-urile salvate sau copiile corespunzătoare ale zonelor de memorie, structurilor de date sau registrelor. Verificările sunt activate atât periodic, prin timer, cât și la apariția diferitelor evenimente.

Determinați posibila utilizare a exploit-urilor și blocați atacurile în etapa anterioară accesului la resurse de către nucleu (de exemplu, înainte de a deschide un fișier), dar după ce procesul a obținut privilegii neautorizate (de exemplu, schimbarea UID). La detectarea comportamentului neautorizat al proceselor, acestea sunt în mod implicit terminate forțat, ceea ce este suficient pentru a bloca multe exploatări.

Sursa: opennet.ro