Openwall-Projekt Kernel-Modul-Release (Linux Kernel Runtime Guard), entwickelt, um Angriffe und Verletzungen der Integrität von Kernelstrukturen zu erkennen und zu blockieren. Das Modul kann beispielsweise vor unbefugten Änderungen am laufenden Kernel schützen und versucht, die Berechtigungen von Benutzerprozessen zu ändern (Erkennung der Verwendung von Exploits). Das Modul eignet sich sowohl zur Organisation des Schutzes vor bereits bekannten 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. Projektnummer lizenziert unter GPLv2.
Zu den Änderungen in der neuen Version:
- Die Positionierung des LKRG-Projekts wurde geändert, das nicht mehr in separate Subsysteme zur Überprüfung der Integrität und zur Bestimmung der Verwendung von Exploits unterteilt ist, sondern als vollständiges Produkt zur Identifizierung von Angriffen und verschiedenen Integritätsverletzungen präsentiert wird;
- Die Kompatibilität besteht mit Linux-Kerneln von 5.3 bis 5.7 sowie mit Kerneln, die mit aggressiven GCC-Optimierungen kompiliert wurden, ohne die Optionen CONFIG_USB und CONFIG_STACKTRACE oder mit der Option CONFIG_UNWINDER_ORC, sowie mit Kerneln, die keine LKRG-Hook-Funktionen haben, sofern dies möglich ist darauf verzichtet werden;
- Beim Erstellen werden einige obligatorische CONFIG_*-Kerneleinstellungen überprüft, um aussagekräftige Fehlermeldungen statt obskurer Abstürze zu generieren;
- Unterstützung für die Modi Standby (ACPI S3, Suspend to RAM) und Sleep (S4, Suspend to Disk) hinzugefügt;
- DKMS-Unterstützung zu Makefile hinzugefügt;
- Experimentelle Unterstützung für 32-Bit-ARM-Plattformen wurde implementiert (getestet auf Raspberry Pi 3 Model B). Die bisher verfügbare AArch64 (ARM64)-Unterstützung wurde erweitert, um Kompatibilität mit dem Raspberry Pi 4-Board zu gewährleisten;
- Es wurden neue Hooks hinzugefügt, darunter ein Aufrufhandler von able(), um Exploits, die „manipulieren“, besser zu identifizieren.", keine Prozess-IDs ();
- Es wurde eine neue Logik zur Erkennung von Versuchen vorgeschlagen, Namespace-Beschränkungen zu umgehen (z. B. von Docker-Containern);
- Auf x86-64-Systemen wird das SMAP-Bit (Supervisor Mode Access Prevention) überprüft und angewendet, um den Zugriff auf Benutzerraumdaten durch privilegierten Code zu blockieren, der auf Kernelebene ausgeführt wird. Der SMEP-Schutz (Supervisor Mode Execution Prevention) wurde bereits implementiert.
- Während des Betriebs werden die LKRG-Einstellungen in einer Speicherseite abgelegt, die normalerweise nur lesbar ist;
- Die Protokollierung von Informationen, die für Angriffe am nützlichsten sein können (z. B. Informationen über Adressen im Kernel), ist auf den Debugging-Modus (log_level=4 und höher) beschränkt, der standardmäßig deaktiviert ist.
- Die Skalierbarkeit der Prozessverfolgungsdatenbank wurde erhöht – anstelle eines durch einen Spinlock geschützten RB-Baums wird eine Hash-Tabelle mit 512 RB-Bäumen verwendet, die durch 512 Lese-/Schreibsperren geschützt sind;
- Es wurde ein Modus implementiert und standardmäßig aktiviert, in dem die Integrität von Prozesskennungen häufig nur für die aktuelle Aufgabe und optional auch für aktivierte (aufweckende) Aufgaben überprüft wird. Bei anderen Aufgaben, die sich im Ruhezustand befinden oder ohne Zugriff auf die von LKRG gesteuerte Kernel-API arbeiten, wird die Prüfung seltener durchgeführt.
- Neue Sysctl- und Modulparameter zur Feinabstimmung von LKRG sowie zwei Sysctl zur vereinfachten Konfiguration durch Auswahl aus von den Entwicklern vorbereiteten Sätzen von Feinabstimmungseinstellungen (Profilen) hinzugefügt;
- Die Standardeinstellungen wurden geändert, um ein ausgewogeneres Gleichgewicht zwischen der Geschwindigkeit der Erkennung von Verstößen und der Wirksamkeit der Reaktion einerseits und den Auswirkungen auf die Leistung und dem Risiko falsch positiver Ergebnisse andererseits zu erreichen.
- Die Systemd-Unit-Datei wurde neu gestaltet, um das LKRG-Modul früh beim Booten zu laden (eine Kernel-Befehlszeilenoption kann verwendet werden, um das Modul zu deaktivieren);
Unter Berücksichtigung der in der neuen Version vorgeschlagenen Optimierungen wird die Leistungsreduzierung bei Verwendung von LKRG 0.8 im Standardmodus („Heavy“) auf 2.5 % und im Light-Modus („Light“) auf 2 % geschätzt.
In einem kürzlich abgehaltenen Wirksamkeit von Paketen zur Erkennung von Rootkits LKRG beste Ergebnisse, indem 8 von 9 getesteten Rootkits identifiziert wurden, die auf Kernel-Ebene ohne Fehlalarme funktionieren (die Rootkits Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit und Sutekh wurden identifiziert, aber Keysniffer, ein Kernel). Modul, wurde mit einem Keylogger übersehen, nicht mit einem Rootkit im wörtlichen Sinne). Zum Vergleich: Die Pakete AIDE, OSSEC und Rootkit Hunter erkannten zwei von neun Rootkits, während Chkrootkit keines entdeckte. Gleichzeitig unterstützt LKRG nicht die Erkennung von Rootkits, die sich im Benutzerbereich befinden, sodass die größte Effizienz durch die Verwendung einer Kombination aus AIDE und LKRG erreicht wird, die es ermöglichte, 2 von 9 Rootkits aller Art zu identifizieren.
Darüber hinaus kann darauf hingewiesen werden, dass der Distributionsentwickler begonnen fertige Pakete mit DKMS für Debian, Whonix, Qubes und Kicksecure sowie ein Paket für bereits auf Version 0.8 aktualisiert. Pakete mit LKRG sind auch auf Russisch verfügbar и .
Die Integritätsprüfung in LKRG erfolgt durch den Vergleich des tatsächlichen Codes und der Daten des Kernels und der Module, einiger wichtiger Datenstrukturen und CPU-Einstellungen mit gespeicherten Hashes oder Kopien der entsprechenden Speicherbereiche, Datenstrukturen oder Register. Die Prüfungen werden sowohl periodisch per Timer als auch beim Eintreten verschiedener Ereignisse aktiviert.
Die Bestimmung der möglichen Nutzung von Exploits und das Blockieren von Angriffen erfolgt in der Phase, bevor der Kernel Zugriff auf Ressourcen gewährt (z. B. vor dem Öffnen einer Datei), aber nachdem der Prozess nicht autorisierte Berechtigungen erhalten hat (z. B. Ändern der UID). Wenn unbefugtes Verhalten erkannt wird, werden Prozesse standardmäßig zum Beenden gezwungen, was ausreicht, um viele Exploits zu blockieren.
Source: opennet.ru