Openwall projekt a kernelmód fejlesztése (Linux Kernel Runtime Guard), amely a kernel struktúrák támadásainak és integritás sértéseknek a felfedezésére és blokkolására szolgál. Például a modul védelmet nyújthat a működő kernelben végrehajtott jogosulatlan módosításokkal és a felhasználói folyamatok jogosultságainak megváltoztatására tett kísérletekkel szemben (exploit alkalmazások azonosítása). A modul alkalmas a Linux kernel már ismert exploitjaival szembeni védelem biztosítására (például olyan helyzetekben, amikor a rendszerben nehéz a kernel frissítése), illetve ismeretlen sebezhetőségekre vonatkozó exploitokkal szembeni védekezésre is. A projekt kódja GPLv2 licenc alatt.
Az új verzióban található változások:
- Megváltozott az LKRG projekt pozicionálása, amely most már nem oszlik fel külön alrendszerekre az integritás ellenőrzésére és az exploitok alkalmazásának meghatározására, hanem egy egységes termékként kerül bemutatásra, amely az támadások és különböző integritás sértések felfedezésére szolgál;
- Biztosítva van a kompatibilitás a 5.3 és 5.7 közötti Linux magokkal, valamint olyan magokkal, amelyeket agresszív GCC optimalizálásokkal építettek, CONFIG_USB és CONFIG_STACKTRACE opciók nélkül, vagy CONFIG_UNWINDER_ORC opcióval, valamint olyan magokkal, amelyekből hiányoznak az LKRG által megfigyelhető funkciók, ha ezek nélkül is meg lehet oldani;
- A fordítás során ellenőrzésre kerültek a CONFIG_* kötelező kernelbeállítások, hogy értelmes hibaüzeneteket kapjunk a homályos hibák helyett;
- Hozzáadva a várakozó (ACPI S3, suspend to RAM) és alvó (S4, suspend to disk) módok támogatása;
- A Makefile-ba beépített támogatás az DKMS számára;
- Kísérleti támogatás került bevezetésre a 32 bites ARM platformok számára (tesztelve Raspberry Pi 3 Model B-n). Az előzőleg elérhető AArch64 (ARM64) támogatás kiegészült a Raspberry Pi 4 táblagéppel való kompatibilitással;
- Új horgok (hook) lettek bevezetve, többek között a capable() hívás horgolója a «« meghatározásához, nem pedig a folyamatok azonosítóihoz ();
- Új logika javasolt a névtartományok (például Docker konténerek) korlátozásaiból való kijutási kísérletek azonosítására;
- x86-64 rendszereken biztosítva van a SMAP (Supervisor Mode Access Prevention) bit ellenőrzése és alkalmazása, amely megakadályozza, hogy a felhasználói térben lévő adatokhoz hozzáférjenek a kernel szintjén végrehajtott privilegizált kód. Az SMEP (Supervisor Mode Execution Prevention) védelmet korábban valósították meg;
- A munka során biztosított a LKRG beállításainak elhelyezése a memóriában, amely általában csak olvasható;
- A naplóba írt információk, amelyek a támadások szempontjából a leghasznosabbak lehetnek (például a kernelben lévő címek információja), a hibakeresési mód (log_level=4 és felette) korlátozódnak, amely alapértelmezés szerint ki van kapcsolva.
- Át lett alakítva az adatbázis skálázhatósága a folyamatok nyomon követésére – ahelyett, hogy egy RB fára támaszkodnánk, amely egy spinlockkal van védve, 512 RB fára bővül, amelyeket megfelelően 512 olvasási-írási zamattal védenek.
- Bevezetésre került és alapértelmezés szerint engedélyezésre került egy mód, amelyben a folyamatazonosítók integritásának ellenőrzését gyakran csak a jelenlegi feladat esetében végzik, valamint opcionálisan az aktivált (felébredő) feladatok esetében. A többi, alvó állapotban lévő vagy az LKRG API kerneljével kapcsolatban nem lévő feladatnál ritkábban hajtják végre az ellenőrzést.
- Új sysctl és modulbeállítások kerültek hozzáadásra az LKRG finomhangolásához, valamint két sysctl a fejlesztők által előkészített finomhangolt beállítási készletek (profiles) közötti egyszerűbb választás érdekében;
- Az alapértelmezett beállítások módosították a sérülésekkor való gyors észlelés és a hatékony reakció közötti mérsékelt egyensúly megteremtése érdekében, miközben figyelembe veszik a teljesítményre gyakorolt hatást és a hamis riasztások kockázatát.
- A systemd unit fájl újragondolt a LKRG modul korai betöltésére (a modul kikapcsolásához a kernel parancssori paramétere használható);
A legújabb verzióban javasolt optimalizációk figyelembevételével az LKRG 0.8 használatával járó teljesítménycsökkenés 2,5%-ra becsült a normál üzemmódban („heavy”) és 2%-ra az enyhített üzemmódban („light”).
A nemrégiben végzett a LKRG rootkit-észlelési csomagok hatékonyságáról A legjobb eredmények, hamis riasztások nélkül, a tesztelt 9 rootkit közül 8-at az alapkernel szintjén azonosítva (felfedezett rootkitek: Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit és Sutekh, de a Keysniffer kimaradt, amely egy kernelmodul a keylogger, de nem szigorúan értelmezve rootkit). Összehasonlításképpen, az AIDE, OSSEC és Rootkit Hunter 2 rootkit-et azonosított 9-ből, míg a Chkrootkit egyet sem. Ezenkívül az LKRG nem támogatja a felhasználói térben elhelyezett rootkitek azonosítását, így a legnagyobb hatékonyság az AIDE és az LKRG kombinálásával érhető el, amely lehetővé tette 15 rootkit azonosítását minden típusból.
Továbbá megjegyezhető, hogy a disztribúció fejlesztője megkezdte elkészült csomagokat DKMS számára Debian, Whonix, Qubes és Kicksecure rendszerrel, a csomag pedig már frissítve lett a 0.8-as verzióra. Az LKRG csomagok szintén elérhetők orosz és .
Az LKRG integritás-ellenőrzése az aktuális kód és a kernel adatok, modulok, valamint néhány fontos adatstruktúra és CPU beállítások lementett hash-eivel vagy a megfelelő memória, adatstruktúrák vagy regiszterek másolataival végzett összehasonlításon alapul. Az ellenőrzések időzítő alapján és különböző események bekövetkeztekor is aktiválódnak.
A potenciális exploitable alkalmazások azonosítása és a támadások blokkolása a kernel által a forrásokhoz való hozzáférés biztosítása előtt történik (például a fájl megnyitása előtt), de miután a folyamat jogosulatlan jogosultságokat szerzett (például UID megváltoztatása). Jogosulatlan folyamatok viselkedése esetén alapértelmezetten kényszerített leállítás történik, ami elegendő számos exploit blokkolásához.
Forrás: opennet.ru
