Veröffentlichung des Moduls LKRG 0.8 zum Schutz vor der Ausnutzung von Schwachstellen im Linux-Kernel

Openwall-Projekt veröffentlichte Erscheinung des Kernel-Moduls LKRG 0.8 (Linux Kernel Runtime Guard), das zur Erkennung und Blockierung von Angriffen und zur Wahrung der Integrität von Kernel-Strukturen entwickelt wurde. Zum Beispiel kann das Modul vor unbefugten Änderungen am laufenden Kernel sowie vor Versuchen schützen, die Berechtigungen von Benutzerprozessen zu ändern (Bestimmung der Nutzung von Exploits). Das Modul eignet sich sowohl zur Sicherung gegen bereits bekannte Exploits für den Linux-Kernel (z. B. in Situationen, in denen es schwierig ist, den Kernel im System zu aktualisieren) als auch zur Abwehr von Exploits für noch unbekannte Schwachstellen. Projektcode wird verbreitet unter der GPLv2-Lizenz.

Zu den Neuerungen in der neuen Version gehören:

• Die Positionierung des LKRG-Projekts wurde geändert, sodass es nun nicht mehr in separate Subsysteme zur Integritätsprüfung und zur Bestimmung der Nutzung von Exploits unterteilt wird, sondern als ein einheitliches Produkt zur Erkennung von Angriffen und verschiedenen Verstößen gegen die Integrität präsentiert wird;
• Kompatibilität mit Linux-Kernels von 5.3 bis 5.7 wurde gewährleistet, sowie mit Kernen, die mit aggressiven GCC-Optimierungen, ohne die Optionen CONFIG_USB und CONFIG_STACKTRACE oder mit der Option CONFIG_UNWINDER_ORC, sowie mit Kernen, in denen die abfangbaren LKRG-Funktionen fehlen, soweit darauf verzichtet werden kann;
• Bei der Erstellung wird die Überprüfung bestimmter erforderlicher Kernel-Einstellungen CONFIG_* sichergestellt, um sinnvolle Fehlermeldungen anstelle von unklaren Abstürzen zu generieren;
• Unterstützung für den Wartemodus (ACPI S3, Suspend to RAM) und den Schlafmodus (S4, Suspend to Disk) wurde hinzugefügt;
• Die Unterstützung von DKMS wurde in die Makefile integriert;
• Experimentelle Unterstützung für 32-Bit-ARM-Plattformen wurde implementiert (getestet auf Raspberry Pi 3 Model B). Die zuvor verfügbare Unterstützung für AArch64 (ARM64) wurde um die Sicherstellung der Kompatibilität mit der Platine Raspberry Pi 4 erweitert;
• Neue Hooks wurden hinzugefügt, einschließlich des Hooks für den Aufruf capable() zur besseren Bestimmung von Exploits, die mit „Capabilities festzulegen“, und nicht mit Prozess-IDs (credentials);
• Eine neue Logik zur Bestimmung von Versuchen, Einschränkungen von Namensräumen (z. B. aus Docker-Containern) zu umgehen, wurde vorgeschlagen;
• Auf x86-64-Systemen erfolgt die Überprüfung und Anwendung des SMAP-Bits (Supervisor Mode Access Prevention), das den Zugriff auf Daten im Benutzerspeicher aus privilegiertem Code, der im Kernel-Modus ausgeführt wird, blockiert. Der Schutz SMEP (Supervisor Mode Execution Prevention) wurde bereits zuvor implementiert;
• Während des Betriebs wird sichergestellt, dass die LKRG-Einstellungen in einem normalerweise nur lesbaren Speicherbereich abgelegt werden;
• Die Ausgabe von Informationen, die für Angriffe am nützlichsten sein könnten (z. B. Informationen zu Adressen im Kernel), ist auf den Debug-Modus (log_level=4 und höher) beschränkt, der standardmäßig deaktiviert ist.
• Die Skalierbarkeit der Prozessüberwachungs-Datenbank wurde erhöht – anstelle eines einzelnen RB-Baums, der durch einen Spinlock geschützt wird, wird eine Hashtabelle aus 512 RB-Bäumen verwendet, die jeweils durch 512 Lese-/Schreiblocks geschützt sind;
• Es wurde ein Modus implementiert und standardmäßig aktiviert, in dem die Integritätsprüfung der Prozessidentifikatoren häufig nur für die aktuelle Aufgabe und optional für aktivierte (aufwachende) Aufgaben durchgeführt wird. Für die anderen Aufgaben, die sich im Ruhezustand befinden oder ohne Zugriff auf die vom LKRG-API bereitgestellte Kernel-API laufen, wird die Prüfung seltener durchgeführt.
• Neue sysctl und Modulpunkte wurden hinzugefügt, um LKRG fein abzustimmen, sowie zwei sysctl zur vereinfachten Konfiguration durch Auswahl aus von den Entwicklern vorbereiteten Feineinstellungen (Profiles);
• Die Standardkonfigurationen wurden geändert, um ein ausgewogeneres Gleichgewicht zwischen der Reaktionsschnelligkeit bei der Erkennung von Verstößen einerseits und dem Einfluss auf die Leistung sowie dem Risiko von Fehlalarmen andererseits zu erzielen;
• Die systemd-Unit-Datei wurde überarbeitet, um das LKRG-Modul in einem frühen Ladeprozess zu laden (zum Deaktivieren des Moduls kann ein Kernel-Befehlszeilenparameter verwendet werden);

Mit den im neuen Release vorgeschlagenen Optimierungen wird der Leistungsabfall bei der Anwendung von LKRG 0.8 auf 2,5 % im Standardmodus („heavy“) und 2 % im leichten Modus („light“) geschätzt.

In einer kürzlich durchgeführten der Untersuchung Effektivität von Paketen zur Erkennung von Rootkits durch LKRG zeigte Die besten Ergebnisse ohne Fehlalarme lieferten 8 von 9 getesteten Rootkits, die auf Kernel-Ebene arbeiten (es wurden die Rootkits Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit und Sutekh identifiziert, während Keysniffer, ein Kernel-Modul mit einem Keylogger und kein Rootkit im eigentlichen Sinne, übersehen wurde). Zum Vergleich haben die Pakete AIDE, OSSEC und Rootkit Hunter 2 Rootkits von 9 identifiziert, während Chkrootkit keins gefunden hat. Dabei unterstützt LKRG nicht die Erkennung von Rootkits, die im Benutzerspeicher platziert sind, sodass die höchste Effizienz bei der Verwendung der Kombination AIDE und LKRG erzielt wird, was die Identifizierung von 14 von 15 Rootkits aller Typen ermöglicht.

Zusätzlich kann angemerkt werden, dass der Entwickler des Distributionspakets Whonix begonnen wird gebildet fertige Pakete mit DKMS für Debian, Whonix, Qubes und Kicksecure bereitstellt, und das Paket für Arch Linux bereits auf Version 0.8 aktualisiert wurde. Pakete mit LKRG sind ebenfalls in russischen In die Version des Dateimanagers PCManFM-Qt und die zugrunde liegende Bibliothek LibFM-Qt wurde die Unterstützung für den Einfensterbetrieb (ohne Dialoge in separaten Fenstern) hinzugefügt. und Astra Linux.

Die Integritätsprüfung in LKRG erfolgt anhand des Vergleichs des aktuellen Codes und der Daten des Kernels sowie der Module, einiger wichtiger Datenstrukturen und CPU-Einstellungen mit den gespeicherten Hashes oder Kopien der entsprechenden Speicherbereiche, Datenstrukturen oder Register. Die Prüfungen werden sowohl regelmäßig durch einen Timer als auch beim Auftreten verschiedener Ereignisse aktiviert.

Die Identifizierung möglicher Exploit-Anwendungen und die Blockierung von Angriffen erfolgt in der Phase, bevor der Kernel Zugriff auf die Ressourcen gewährt (z. B. vor dem Öffnen einer Datei), aber nachdem der Prozess unbefugte Berechtigungen erhalten hat (z. B. UID-Wechsel). Bei Erkennung von unbefugtem Verhalten von Prozessen wird standardmäßig deren sofortige Beendigung durchgeführt, was ausreicht, um viele Exploits zu blockieren.

Quelle: opennet.ru