Erscheinung des LKRG-Moduls 0.8 zum Schutz vor der Ausnutzung von Schwachstellen im Linux-Kernel

Openwall-Projekt veröffentlichte Veröffentlichung des Kernel-Moduls LKRG 0.8 (Linux Kernel Runtime Guard), welches zur Erkennung und Blockierung von Angriffen und zur Aufrechterhaltung der Integrität von Kernelstrukturen entwickelt wurde. Das Modul schützt beispielsweise vor unerlaubten Änderungen am laufenden Kernel und vor Versuchen, die Berechtigungen von Benutzerprozessen zu verändern (Erkennung der Ausnutzung von Exploits). Es eignet sich sowohl zum Schutz vor bereits bekannten Exploits für den Linux-Kernel (z. B. in Situationen, in denen das System schwer zu aktualisieren ist), als auch zur Abwehr von Exploits für noch unbekannte Schwachstellen. Projektcode wird unter der GPLv3-Lizenz bereitgestellt. steht unter der GPLv2-Lizenz.

Zu den Änderungen in der neuen Version gehören:

• Die Positionierung des LKRG-Projekts wurde geändert; es wird jetzt nicht mehr in separate Subsysteme zur Integritätsprüfung und zur Erkennung von Exploits unterteilt, sondern als ein umfassendes Produkt zur Erkennung von Angriffen und verschiedenen Integritätsverletzungen präsentiert.
• Die Kompatibilität mit Linux-Kernel-Versionen von 5.3 bis 5.7 sowie mit Kernels, die mit aggressiven GCC-Optimierungen ohne die Optionen CONFIG_USB und CONFIG_STACKTRACE oder mit der Option CONFIG_UNWINDER_ORC kompiliert wurden, wurde gewährleistet, ebenso wie mit Kernels, in denen LKRG-Funktionen, die abgefangen werden könnten, nicht vorhanden sind, wenn diese nicht benötigt werden.
• Bei der Erstellung wird die Überprüfung bestimmter obligatorischer CONFIG_* Kernel-Einstellungen sichergestellt, um sinnvolle Fehlermeldungen anstelle von unklaren Ausfällen zu erzeugen;
• Unterstützung für den Standby-Modus (ACPI S3, Suspend to RAM) und den Schlafmodus (S4, Suspend to Disk) wurde hinzugefügt;
• Unterstützung für DKMS wurde im Makefile hinzugefügt;
• 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 Kompatibilität mit der Raspberry Pi 4-Platine ergänzt;
• Neue Handler (Hooks) wurden hinzugefügt, einschließlich des capable()-Handlers zur besseren Identifizierung von Exploits, die mit "Capabilities festzulegen." anstelle von Prozess-IDs (credentials);
• Eine neue Logik zur Bestimmung von Versuchen, die Einschränkungen von Namespaces (z. B. aus Docker-Containern) zu verlassen, wurde vorgeschlagen;
• Auf x86-64-Systemen wurde die Überprüfung und Anwendung des SMAP-Bits (Supervisor Mode Access Prevention) sichergestellt, das darauf abzielt, den Zugriff auf Benutzerdaten durch privilegierten Code, der im Kernel-Modus ausgeführt wird, zu blockieren. Der Schutz durch SMEP (Supervisor Mode Execution Prevention) wurde zuvor umgesetzt;
• Während des Betriebs werden die Einstellungen von LKRG im normalerweise nur lesbaren Speicher abgelegt.
• Die Protokollausgabe von Informationen, die für Angriffe am nützlichsten sein könnten (zum Beispiel Informationen über Adressen im Kernel), ist auf den Debug-Modus (log_level=4 und höher) beschränkt, der standardmäßig deaktiviert ist.
• Die Skalierbarkeit der Prozessverfolgungsdatenbank wurde verbessert – anstelle eines einzelnen RB-Baums, der durch ein Spinlock geschützt ist, wird eine Hashtabelle mit 512 RB-Bäumen verwendet, die jeweils durch 512 Lese-Schreib-Sperren geschützt sind.
• Ein Modus wurde implementiert und standardmäßig aktiviert, bei dem die Integritätsprüfung der Prozess-IDs häufig nur für die aktuelle Aufgabe durchgeführt wird sowie optional für aktivierte (aufwachende) Aufgaben. Für andere Aufgaben, die im Schlafzustand sind oder ohne Kontakt zur LKRG API des Kernels arbeiten, erfolgt die Überprüfung seltener.
• Neue sysctl- und Modulparameter wurden hinzugefügt, um LKRG fein abzustimmen, ebenso zwei sysctl zur Vereinfachung der Konfiguration durch Auswahl aus vordefinierten, vom Entwickler bereitgestellten Feinabstimmungsprofilen.
• Die Standardkonfigurationen wurden geändert, um ein besseres Gleichgewicht zwischen der Geschwindigkeit der Erkennung von Verstößen und der Reaktionsfähigkeit sowie der Auswirkung auf die Leistung und dem Risiko von Fehlalarmen zu erreichen.
• Die systemd-Unitdatei wurde überarbeitet, um das LKRG-Modul früh im Bootprozess zu laden (um das Modul zu deaktivieren, kann ein Kernel-Befehlszeilenparameter verwendet werden).

Mit den im neuen Release vorgeschlagenen Optimierungen wird die Leistungseinbuße bei Verwendung von LKRG 0.8 auf 2,5 % im Standardmodus ("heavy") und 2 % im leichten Modus ("light") geschätzt.

In der kürzlich durchgeführten Studie Effizienz der Pakete zur Erkennung von Rootkits LKRG ergab beste Ergebnisse ohne falsche Alarme, indem 8 von 9 getesteten Rootkits ermittelt wurden, die auf Kernel-Ebene arbeiten (es wurden die Rootkits Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit und Sutekh identifiziert, jedoch wurde Keysniffer, das ein Kernel-Modul mit Keylogger ist, nicht erfasst, da es kein Rootkit im eigentlichen Sinne ist). Zum Vergleich: Die Pakete AIDE, OSSEC und Rootkit Hunter identifizierten 2 Rootkits von 9, während Chkrootkit keines nachwies. Es ist zu beachten, dass LKRG keine Rootkits erkennt, die im User-Space platziert sind, daher wird die größte Effizienz durch die Kombination von AIDE und LKRG erreicht, die 14 von 15 Rootkits aller Typen identifiziert hat.

Zusätzlich ist zu erwähnen, dass der Entwickler der Distribution Whonix alle HTTP-Webseiten als „nicht sicher“ zu kennzeichnen. wird die fertige Pakete mit DKMS für Debian, Whonix, Qubes und Kicksecure bereitstellt, während das Paket für Arch Linux bereits auf Version 0.8 aktualisiert wurde. Pakete mit LKRG sind ebenfalls in den russischen ALT Linux und Astra Linux.

Die Integritätsprüfung in LKRG erfolgt durch den Vergleich des aktuellen Codes und der Daten von Kernel und Modulen, wichtiger Datenstrukturen und CPU-Einstellungen mit gespeicherten Hashes oder Kopien der entsprechenden Speicherbereiche, Datenstrukturen oder Register. Die Prüfungen werden sowohl regelmäßig über einen Timer als auch bei verschiedenen Ereignissen aktiviert.

Die Erkennung möglicher Ausnutzung von Schwachstellen und die Blockierung von Angriffen erfolgen, bevor der Kernel den Zugriff auf Ressourcen gewährt (z. B. vor dem Öffnen einer Datei), aber nachdem der Prozess unbefugte Berechtigungen erhalten hat (z. B. bei einer UID-Änderung). Bei festgestelltem unbefugtem Verhalten von Prozessen erfolgt standardmäßig deren zwangsweise Beendigung, was ausreicht, um viele Exploits zu blockieren.

Quelle: opennet.ru