Lëshimi i modulit LKRG 0.8 për të mbrojtur kundër shfrytëzimit të dobësive në kernelin Linux

Projekti Openwall publikuar lëshimi i modulit të kernelit LKRG 0.8 (Linux Kernel Runtime Guard), i projektuar për të zbuluar dhe bllokuar sulmet dhe shkeljet e integritetit të strukturave të kernelit. Për shembull, moduli mund të mbrojë kundër ndryshimeve të paautorizuara në kernelin e ekzekutuar dhe përpjekjeve për të ndryshuar lejet e proceseve të përdoruesit (duke zbuluar përdorimin e shfrytëzimeve). Moduli është i përshtatshëm si për organizimin e mbrojtjes kundër shfrytëzimeve tashmë të njohura për kernelin Linux (për shembull, në situata ku është e vështirë të përditësohet kerneli në sistem), ashtu edhe për të luftuar shfrytëzimet për dobësi ende të panjohura. Kodi i projektit shperndare nga licencuar sipas GPLv2.

Ndër ndryshimet në versionin e ri:

• Është ndryshuar pozicionimi i projektit LKRG, i cili nuk ndahet më në nënsisteme të veçanta për kontrollin e integritetit dhe përcaktimin e përdorimit të shfrytëzimeve, por paraqitet si një produkt i plotë për identifikimin e sulmeve dhe shkeljeve të ndryshme të integritetit;
• Përputhshmëria ofrohet me kernelet Linux nga 5.3 deri në 5.7, si dhe me kernelet e përpiluara me optimizime agresive të GCC, pa opsionet CONFIG_USB dhe CONFIG_STACKTRACE ose me opsionin CONFIG_UNWINDER_ORC, si dhe me kernelet që nuk kanë funksione të LKRG, nëse ato janë të lidhura. të shpërndahet;
• Gjatë ndërtimit, disa cilësime të detyrueshme të kernelit CONFIG_* kontrollohen për të gjeneruar mesazhe gabimi kuptimplotë në vend të përplasjeve të paqarta;
• Mbështetje e shtuar për modalitetet e gatishmërisë (ACPI S3, pezullimi në RAM) dhe gjumit (S4, pezullimi në disk);
• U shtua mbështetje DKMS në Makefile;
• Është zbatuar mbështetja eksperimentale për platformat ARM 32-bit (e testuar në Raspberry Pi 3 Model B). Mbështetja e disponueshme më parë AArch64 (ARM64) është zgjeruar për të siguruar përputhshmëri me bordin e Raspberry Pi 4;
• Janë shtuar grepa të reja, duke përfshirë një mbajtës thirrjesh të aftë() për të identifikuar më mirë shfrytëzimet që manipulojnë "aftësitë", mos përpunoni ID-të (letra kredenciale);
• Një logjikë e re është propozuar për zbulimin e përpjekjeve për t'i shpëtuar kufizimeve të hapësirës së emrave (për shembull, nga kontejnerët Docker);
• Në sistemet x86-64, kontrollohet dhe zbatohet biti SMAP (Supervisor Mode Access Prevention), i krijuar për të bllokuar aksesin në të dhënat e hapësirës së përdoruesit nga kodi i privilegjuar që ekzekutohet në nivelin e kernelit. Mbrojtja SMEP (Supervisor Mode Execution Prevention) është zbatuar më parë;
• Gjatë funksionimit, cilësimet LKRG vendosen në një faqe memorie që zakonisht është vetëm për lexim;
• Regjistrimi i informacionit që mund të jetë më i dobishëm për sulmet (për shembull, informacioni rreth adresave në kernel) është i kufizuar në modalitetin e korrigjimit (log_level=4 dhe më i lartë), i cili është i çaktivizuar si parazgjedhje.
• Shkallueshmëria e bazës së të dhënave të përcjelljes së procesit është rritur - në vend të një peme RB të mbrojtur nga një spinlock, përdoret një tabelë hash prej 512 pemësh RB të mbrojtura nga 512 bravë leximi-shkrimi;
• Një modalitet është implementuar dhe aktivizuar si parazgjedhje, në të cilin integriteti i identifikuesve të procesit shpesh kontrollohet vetëm për detyrën aktuale, dhe gjithashtu opsionalisht për detyrat e aktivizuara (zgjimin). Për detyra të tjera që janë në gjendje gjumi ose që punojnë pa akses në API të kernelit të kontrolluar nga LKRG, kontrolli kryhet më rrallë.
• U shtuan parametra të rinj sysctl dhe moduli për rregullimin e mirë të LKRG, si dhe dy sysctl për konfigurim të thjeshtuar duke zgjedhur nga grupet e cilësimeve (profileve) të rregullimit të imët të përgatitur nga zhvilluesit;
• Cilësimet e parazgjedhura janë ndryshuar për të arritur një ekuilibër më të ekuilibruar midis shpejtësisë së zbulimit të shkeljeve dhe efektivitetit të përgjigjes, nga njëra anë, dhe ndikimit në performancë dhe rrezikut të rezultateve false, nga ana tjetër;
• Skedari i njësisë systemd është ridizajnuar për të ngarkuar modulin LKRG herët në nisje (mund të përdoret një opsion i linjës së komandës së kernelit për të çaktivizuar modulin);

Duke marrë parasysh optimizimet e propozuara në versionin e ri, ulja e performancës kur përdoret LKRG 0.8 vlerësohet në 2.5% në modalitetin e paracaktuar ("i rëndë") dhe 2% në modalitetin e lehtë ("i lehtë").

Në një të mbajtur së fundmi studim efektiviteti i paketave për zbulimin e rootkits LKRG tregoi rezultatet më të mira, duke identifikuar 8 nga 9 rootkits të testuar që punojnë në nivel kernel pa rezultate false (rootkits Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit dhe Sutekh u identifikuan, por Keysniffer, i cili është një moduli, u mungua me një keylogger, jo një rootkit në kuptimin e mirëfilltë). Për krahasim, paketat AIDE, OSSEC dhe Rootkit Hunter zbuluan 2 nga 9 rootkits, ndërsa Chkrootkit nuk zbuloi asnjë. Në të njëjtën kohë, LKRG nuk mbështet zbulimin e rootkits të vendosura në hapësirën e përdoruesit, kështu që efikasiteti më i madh arrihet kur përdoret një kombinim i AIDE dhe LKRG, gjë që bëri të mundur identifikimin e 14 nga 15 rootkits të të gjitha llojeve.

Për më tepër, mund të vërehet se zhvilluesi i shpërndarjes Whonix filloi formësimin paketa të gatshme me DKMS për Debian, Whonix, Qubes dhe Kicksecure dhe një paketë për Arch Linux tashmë i përditësuar në versionin 0.8. Paketat me LKRG janë gjithashtu të disponueshme në Rusisht alt linux и AstraLinux.

Kontrolli i integritetit në LKRG kryhet duke krahasuar kodin dhe të dhënat aktuale të kernelit dhe moduleve, disa struktura të rëndësishme të dhënash dhe cilësime të CPU-së me hash-et e ruajtura ose kopjet e zonave të memories përkatëse, strukturave të të dhënave ose regjistrave. Kontrollet aktivizohen si periodikisht me kohëmatës ashtu edhe me ndodhjen e ngjarjeve të ndryshme.

Përcaktimi i përdorimit të mundshëm të shfrytëzimeve dhe sulmeve të bllokimit kryhet në fazën përpara se kerneli të sigurojë akses në burime (për shembull, para hapjes së një skedari), por pasi procesi të ketë marrë leje të paautorizuara (për shembull, ndryshimi i UID). Kur zbulohet sjellje e paautorizuar, proceset detyrohen të përfundojnë si parazgjedhje, gjë që mjafton për të bllokuar shumë shfrytëzime.

Burimi: opennet.ru