Projet Openwall publication du module du noyau (Linux Kernel Runtime Guard), destiné à détecter et bloquer les attaques et les violations d'intégrité des structures du noyau. Par exemple, le module peut protéger contre les modifications non autorisées d'un noyau en fonctionnement et les tentatives de modification des permissions des processus utilisateur (détection de l'utilisation d'exploits). Le module convient à la fois à la protection contre des exploits déjà connus pour le noyau Linux (par exemple, dans des situations où la mise à jour du noyau dans le système est problématique) et à la résistance aux exploits d'inconnues vulnérabilités. Code du projet sous licence GPLv2.
Parmi les changements dans la nouvelle version :
- Le positionnement du projet LKRG a été modifié, il n'est plus divisé en sous-systèmes distincts pour vérifier l'intégrité et détecter l'utilisation d'exploits, mais est présenté comme un produit intégré pour détecter les attaques et diverses violations d'intégrité ;
- La compatibilité avec les noyaux Linux de 5.3 à 5.7 a été assurée, ainsi qu'avec les noyaux compilés avec des optimisations agressives de GCC, sans les options CONFIG_USB et CONFIG_STACKTRACE ou avec l'option CONFIG_UNWINDER_ORC, ainsi qu'avec les noyaux qui n'ont pas de fonctions LKRG interceptables, si cela peut être évité ;
- Lors de la compilation, une vérification de certains paramètres obligatoires du noyau CONFIG_* a été réalisée pour générer des messages d'erreur significatifs au lieu d'échecs peu clairs ;
- Ajout de la prise en charge des modes veille (ACPI S3, suspendre à la RAM) et de mise en veille (S4, suspendre au disque) ;
- Ajout de la prise en charge de DKMS dans le Makefile ;
- Prise en charge expérimentale des plateformes ARM 32 bits (testé sur Raspberry Pi 3 Model B). La prise en charge AArch64 (ARM64) précédemment disponible a été complétée pour assurer la compatibilité avec la carte Raspberry Pi 4 ;
- Ajout de nouveaux hooks, y compris le hook d'appel capable() pour mieux déterminer les exploits manipulant ««, et non des identifiants de processus ();
- Proposition d'une nouvelle logique pour déterminer les tentatives de sortie des limites des espaces de noms (par exemple, hors des conteneurs Docker) ;
- Sur les systèmes x86-64, la vérification et l'application du bit SMAP (Supervisor Mode Access Prevention), destiné à bloquer l'accès aux données dans l'espace utilisateur depuis le code privilégié exécuté au niveau du noyau, ont été assurées. La protection SMEP (Supervisor Mode Execution Prevention) avait été mise en œuvre auparavant ;
- En cours d'exécution, les paramètres LKRG sont stockés dans une page mémoire généralement accessible en lecture seule ;
- La journalisation des informations qui peuvent être les plus utiles pour les attaques (par exemple, les informations d'adresses dans le noyau) est limitée au mode débogage (log_level=4 et plus), désactivé par défaut.
- La scalabilité de la base de données de suivi des processus a été améliorée - au lieu d'un seul arbre RB protégé par un spinlock, une table de hachage composée de 512 arbres RB protégés par 512 verrous de lecture-écriture a été mise en place.
- Un mode a été mis en œuvre et activé par défaut, dans lequel la vérification de l'intégrité des identifiants de processus est souvent effectuée uniquement pour la tâche actuelle, ainsi que de manière optionnelle pour les tâches activées (réveillées). Pour les autres tâches, en veille ou en cours d'exécution sans interaction contrôlée avec l'API LKRG du noyau, la vérification est effectuée moins fréquemment.
- De nouveaux paramètres sysctl et de module ont été ajoutés pour un réglage fin de LKRG, ainsi que deux sysctl pour un réglage simplifié par le choix parmi des ensembles de réglages fins préparés par les développeurs (profils).
- Les paramètres par défaut ont été modifiés pour atteindre un meilleur équilibre entre la rapidité de détection des violations et l'efficacité de la réaction d'une part, et l'impact sur les performances et le risque de faux positifs d'autre part.
- Le fichier de service systemd a été retravaillé pour charger le module LKRG à un stade précoce de l'amorçage (un paramètre de ligne de commande du noyau peut être utilisé pour désactiver le module).
Avec les optimisations proposées dans la nouvelle version, la diminution des performances lors de l'application de LKRG 0.8 est estimée à 2,5 % en mode par défaut (« heavy ») et 2 % en mode allégé (« light »).
Dans une récente étude l'efficacité des paquets pour la détection des rootkits LKRG a obtenu les meilleurs résultats, sans faux positifs, détectant 8 des 9 rootkits testés fonctionnant au niveau du noyau (les rootkits Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit et Sutekh ont été identifiés, mais Keysniffer, qui est un module de noyau avec un keylogger et non un rootkit au sens strict, a été manqué). En comparaison, les paquets AIDE, OSSEC et Rootkit Hunter n'ont détecté que 2 rootkits sur 9, tandis que Chkrootkit n'en a détecté aucun. De plus, LKRG ne supporte pas la détection des rootkits placés dans l'espace utilisateur, donc la plus grande efficacité est atteinte en utilisant la combinaison AIDE et LKRG, qui a permis de détecter 14 des 15 rootkits de tous types.
On peut également noter que le développeur de la distribution avait commencé des paquets prêts à l'emploi avec DKMS pour Debian, Whonix, Qubes et Kicksecure, et le paquet pour a déjà été mis à jour vers la version 0.8. Des paquets avec LKRG sont également présents dans les et .
La vérification de l'intégrité dans LKRG est effectuée sur la base de la comparaison du code et des données du noyau et des modules actuels, de certaines structures de données importantes et des paramètres CPU avec les hachages enregistrés ou les copies des zones de mémoire correspondantes, des structures de données ou des registres. Les vérifications sont activées, soit périodiquement par le minuteur, soit à la suite de divers événements.
La détection des possibles exploits et le blocage des attaques ont lieu au stade précédant l'octroi par le noyau d'accès aux ressources (par exemple, avant l'ouverture d'un fichier), mais après que le processus ait acquis des privilèges non autorisés (par exemple, changement d'UID). Lorsqu'un comportement non autorisé des processus est détecté, ceux-ci sont par défaut terminés de manière forcée, ce qui est suffisant pour bloquer de nombreux exploits.
Source : opennet.ru
