Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.

ModuleJail - Bloquer les modules kernel Linux inutilisés

Vous ne le savez peut-être pas mais votre serveur Linux embarque plusieurs milliers de modules kernel et pourtant, il n'en utilise que quelques centaines à peine. Tout le reste ça prend la poussière et ça peut vous exposer à des problèmes de sécurité. Hé bien c'est exactement à ces modules inutiles que Jasper Nuyens, le fondateur de Linux Belgium, vient s'attaquer avec son outil ModuleJail .

Ce script lit /proc/modules pour savoir ce qui tourne vraiment sur votre machine, et considère ensuite cet ensemble comme étant intouchable. Par contre, pour tout le reste il ajoute une ligne install <module> /bin/true dans /etc/modprobe.d/modulejail-blacklist.conf.

Comme ça si un jour quelque chose essaie de charger un de ces modules endormis, c'est modprobe qui exécutera /bin/true à la place... et il ne se passe rien !!

C'est malin, hein ? Vous pouvez installer ModuleJail via le script dispo sur la page Github ou grâce aux paquets .deb et .rpm si vous préférez. Et ensuite, pour vérifier que c'est bien en place, un petit modprobe -n -v module_banni devrait vous répondre install /bin/true.

En tout cas, je trouve que ModuleJail tombe très bien parce que la chasse aux failles kernel est clairement en train de changer d'échelle. Je pense notamment à tous ces outils de scan assistés par IA qui débusquent à la chaine des bugs d'élévation de privilèges planqués dans le code depuis des années.

Le script propose 3 profils via le flag -p, minimal pour le strict nécessaire, conservative par défaut (serveur classique plus drivers VM courants) et desktop qui garde WiFi, Bluetooth, audio et vidéo. Vous pouvez aussi ajouter votre propre whitelist.

Et la règle d'or non négociable, c'est de le lancer quand la machine est dans un état stable, avec tous les services démarrés, et tous les disques montés. Car oui, ModuleJail ne devine rien, mais se contente de photographier ce qui tourne à l'instant T. Donc sur un système à moitié démarré, ce serait un peu couillon qu'il bannisse un module dont vous aurez besoin plus tard.

Après pour tout ce qui est compilé en dur dans le kernel (le fameux =y de la config) ça reste là, donc une faille dans le cœur du noyau façon Dirty Cow , ça n'y changera rien du tout. Et si vous branchez une webcam six mois après, son module sera déjà banni donc faudra pas oublier de retirer sa ligne du fichier ou relancer le script avec une whitelist, car un simple modprobe ne suffira pas !

Donc c'est pas forcement le pied pour un Linux Desktop mais pour un parc de serveurs en prod qui ne bougent pas, c'est une petite couche de sécurité en plus.

Source

Ne jetez pas votre vieux PC : le noyau Linux s'apprête à booster ses performances en jeu

Sur un PC, l'ordonnanceur du système (le scheduler en anglais), c'est ce petit bout du noyau qui décide quelle tâche tourne sur quel cœur du processeur, et pendant combien de temps. Plus il est malin, plus la machine est fluide.

Peter Zijlstra, l'un des développeurs historiques du noyau Linux, vient de proposer un patch baptisé "sched: Flatten the pick" qui réorganise la façon dont l'ordonnanceur attribue les priorités. Et les résultats sur le gaming, surtout sur du vieux matériel, sont étonnants.

Pour le test, le développeur a sorti un PC d'époque : un Intel Core i7-2600K, processeur de 2011, accompagné d'une carte graphique AMD Radeon RX 580. Le tout fait tourner Shadows: Awakening, un jeu disponible sur la boutique GOG, lancé via Lutris et Proton, l'écosystème qui permet de faire tourner les jeux Windows sous Linux. Et là, surprise.

Avant le patch, le jeu pédalait à environ 4 images par seconde au minimum et 48 en moyenne. Après application, on monte à 20 images par seconde au minimum et 57 en moyenne. Le temps maximum entre deux images, l'autre indicateur clé pour la fluidité, passe de 107 millisecondes à 37. On passe d'injouable à correct. Sur une machine de 2011, c'est presque un miracle.

Le patch touche à la gestion des cgroups, des conteneurs de processus qui regroupent et hiérarchisent les tâches, sur les systèmes multi-cœurs. Plusieurs niveaux de sélection étaient empilés, et le patch les "aplatit" pour gagner en réactivité.

Les vieux processeurs ont moins de cœurs et moins de marge, donc chaque mauvaise décision de l'ordonnanceur coûte cher. Sur un processeur récent avec dix ou douze cœurs, on ne le remarque presque pas. Sur un quadri-cœur d'il y a quinze ans, ça se voit immédiatement à l'écran.

Attention quand même, on n'est pas encore au point d'être intégré dans le noyau Linux officiel. Il reste des relectures et des validations avant que le code finisse en production. C'est la version 2 du patch, donc la discussion technique a déjà bien avancé.

Pour les distributions Linux orientées jeu, qui chassent la moindre milliseconde gagnée, ce genre de patch est exactement le type d'amélioration qu'on suit de près.

Bref, si vous traînez un vieux PC qui peine, un futur noyau Linux pourrait bien lui offrir une deuxième jeunesse pour le jeu.

Source : Itsfoss

Fragnesia - Une nouvelle faille Linux dans la lignée de Dirty Frag

Bon, accrochez vous les amis, car ça enchaine sec sur le kernel Linux en ce moment... Le chercheur William Bowling de l'équipe V12 security vient de lâcher Fragnesia (CVE-2026-46300, CVSS 7.8), un nouvel exploit kernel Linux qui permet d'obtenir un accès root sur toutes les distros majeures, et ce, 8 jours seulement après le patch de Dirty Frag.

Et la mauvaise nouvelle, en fait, c'est que Fragnesia tape dans la même surface d'attaque que Dirty Frag , mais via un bug logique différent qui n'est pas fixé par le patch initial. Donc si vous aviez sagement mis à jour votre noyau le 8 mai dernier en pensant être tranquille, hé bah désolé, vous êtes toujours à poil !

La lignée "Dirty" continue donc tout simplement de s'allonger... Dirty COW en 2016, Dirty Pipe en 2022, Copy Fail le 1er mai 2026, Dirty Frag le 8 mai, et maintenant Fragnesia le 14 mai. Quatre LPE (local privilege escalation) kernel Linux en deux semaines, c'est un record je crois !

Alors comment ça marche ?

Le bug se planque dans la partie du kernel qui gère le chiffrement réseau IPsec. C'est le truc qu'on utilise pour faire du VPN d'entreprise et l'attaque détourne le moteur de chiffrement pour qu'il écrive là où il ne devrait surtout pas écrire.

Le déroulé ensuite est assez simple à comprendre. Il prend un fichier sensible déjà ouvert en lecture (genre /usr/bin/su, le programme qui fait passer en root), il le balance dans une connexion réseau, et il dit au kernel "tiens, chiffre-moi tout ça en IPsec". Le kernel obéit gentiment, sauf qu'au lieu d'envoyer le résultat chiffré sur le réseau, il vient écraser la version du fichier qui est en mémoire avec les octets chiffrés. Du coup /usr/bin/su contient maintenant du code choisi par l'attaquant. Suffit ensuite de taper su pour devenir root.

Et là c'est le drame !

Le pire, c'est qu'il n'y a aucun "tirage au sort" dans tout ça. Pas besoin de gagner une condition de course une fois sur mille comme à l'époque de Dirty COW. Là, c'est 100% reproductible à chaque exécution, ça marche du premier coup.

La cause profonde, c'est une fonction kernel qui assemble des morceaux de paquets réseau et qui oublie au passage que certains morceaux pointent vers de la mémoire qui ne lui appartient pas vraiment (genre la mémoire d'un fichier qu'un autre process est en train de lire). Bowling appelle ça la "famille Dirty Frag" parce que c'est exactement le même genre d'amnésie qui avait permis Dirty Frag la semaine dernière.

Et le patch du 8 mai n'a pas suffi parce qu'il a juste rebouché un trou particulier, sans toucher à la fonction d'origine. D'où la sortie immédiate du PoC le 14 mai, parce qu'autant prévenir tout le monde, plutôt que de laisser un 0-day silencieux circuler dans les milieux moins recommandables d'Internet.

Testez sur votre Linux

Si vous voulez reproduire ça dans un environnement isolé (genre une VM Ubuntu 24.04 avec un kernel 6.8.0-111-generic), c'est simple :

git clone https://github.com/v12-security/pocs.git
cd pocs/fragnesia
gcc -o exp fragnesia.c && ./exp

Petite subtilité à connaître sur Ubuntu, AppArmor restreint les "user namespaces" (les bacs à sable du kernel) pour les utilisateurs non-privilégiés depuis Ubuntu 24.04. Du coup, avant de lancer l'exploit, faut faire sauter ce verrou de sécurité :

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

Et là vous récupérez un shell root sans crasher le kernel... vous allez voir, c'est presque magique !

⚠️ Attention, après le test, le /usr/bin/su en mémoire est toujours pété (il contient encore le code de l'attaquant). Donc avant de continuer à utiliser la machine, faut nettoyer ce cache mémoire :

echo 3 > /proc/sys/vm/drop_caches

Ou plus simple, vous rebootez la VM puisque la corruption est uniquement en RAM.

Alors on fait quoi maintenant ?

D'abord, du côté patch, AlmaLinux a déjà sorti des kernels corrigés (kernel-4.18.0-553.124.3.el8_10 pour AL8, kernel-5.14.0-611.54.5.el9_7 pour AL9, et kernel-6.12.0-124.56.3.el10_1 pour AL10). Ensuite, pour les autres distros (Ubuntu, Debian, RHEL, SUSE, Fedora, Gentoo, Amazon Linux, CloudLinux), c'est en cours, mais pas encore disponible partout à l'heure où j'écris ces lignes.

En attendant, la mitigation est exactement la même que pour Dirty Frag, ce qui est plutôt cool, et même pratique, si vous l'aviez déjà appliquée la semaine dernière (rien à refaire, vous êtes déjà protégé contre la nouvelle bête, c'est cadeau). Si ce n'est pas le cas, voici la commande à coller en root, à exécuter sur chaque machine concernée :

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"

Cette ligne bloque les trois modules vulnérables (esp4, esp6 et rxrpc) pour qu'ils ne se rechargent pas au reboot, les décharge s'ils tournent déjà, et nettoie le cache mémoire au cas où il serait déjà corrompu.

Pour rappel, ces trois modules ne servent qu'à du VPN IPsec en mode transport et à un protocole réseau exotique d'Andrew File System. Du coup, 99% des desktops et serveurs classiques ne perdent rien à les désactiver. Si vous opérez du VPN IPsec en prod par contre, là attention, faudra attendre le patch officiel de votre distro et bricoler une rotation de modules en attendant.

Une fois que votre distro pousse le patch officiel (espérons que ce sera très bientôt côté Ubuntu et Debian), vous mettez à jour le noyau, vous rebootez la bécane, et vous retirez tranquillement la conf de modprobe.

Source : github.com/v12-security/pocs

KDE 6.6.5 corrige des bugs gênants avant l’arrivée de Plasma 6.7

KDE PlasmaÀ quelques semaines du lancement de KDE Plasma 6.7, le projet KDE publie une mise à jour corrective estampillée KDE Plasma 6.6.5. Elle se focalise principalement sur plusieurs problèmes importants apparus récemment, notamment autours des pilotes graphiques NVIDIA 595. Des corrections de bugs Cette mise à jour se concentre avant tout sur la stabilité, les …

Cet article KDE 6.6.5 corrige des bugs gênants avant l’arrivée de Plasma 6.7 a été publié en premier par GinjFo.

« Je n’ai aucun problème avec ça » : Peter Jackson dédramatise l’IA au cinéma

Peter Jackson, qui a porté Le Seigneur des anneaux sur grand écran, vient-il de trahir l'art du cinéma ou fait-il preuve de pragmatisme ? Présent au Festival de Cannes 2026 pour recevoir une Palme d'or d'honneur, le cinéaste a jeté un pavé dans la mare en déclarant qu'il « ne déteste pas » l'usage de l'intelligence artificielle dans les films. Entre défense du réalisme et aveu d'impuissance, ses propos risquent de diviser une industrie à cran sur cette question.

OpenZFS 2.4.2 sort avec le support du noyau Linux 7.0

OpenZFS 2.4.2 est sortie ce 12 mai, et c'est une mise à jour qu'attendaient pas mal de gens qui font tourner du Linux 7.0 (le tout dernier noyau Linux stable). OpenZFS, pour ceux qui ne suivent pas, c'est le portage libre du célèbre système de fichiers ZFS originellement développé par Sun Microsystems, et désormais maintenu par une communauté autour de FreeBSD et Linux.

ZFS, en gros, c'est ce qui permet de gérer des pools de disques de plusieurs téraoctets avec snapshots, compression, déduplication et auto-réparation des données. Le genre d'outil qu'on retrouve dans les NAS sérieux et les serveurs de stockage.

La grosse nouveauté de cette 2.4.2, c'est le support du noyau Linux 7.0 stable. La version précédente 2.4.1 plafonnait à Linux 6.19, et beaucoup d'admins qui ont mis à jour leur distribution se retrouvaient avec un système qui refusait de charger le module ZFS.

C'est résolu. La compatibilité historique est aussi maintenue jusqu'à Linux 4.18, ce qui permet aux serveurs un peu anciens de continuer à profiter des dernières corrections. Côté BSD, FreeBSD 13.3 et plus restent supportés.

Dans le détail des changements, on trouve des corrections sur initramfs (le système qui charge le noyau au démarrage), le support de l'appel système POSIX_FADV_DONTNEED qui permet à une application de dire au noyau qu'elle n'a plus besoin d'un fichier en cache (ce qui libère de la RAM), les premiers patchs préparatoires pour Linux 7.1, et un durcissement des en-têtes SPDX (les balises de licence en tête de chaque fichier). Rien de spectaculaire, mais c'est ce genre de maintenance discrète qui fait tenir un projet sur la durée.

Pour ceux qui ne veulent pas passer sur la branche 2.4, l'équipe a aussi publié OpenZFS 2.3.7 en parallèle. Mêmes corrections de stabilité, kernels supportés un peu plus anciens. Ça permet aux infrastructures conservatrices de rester sur leur branche sans rater les fixes importants.

Si vous tournez sur Proxmox, TrueNAS, ou un Linux avec ZFS en racine, allez donc vérifier la version dispo dans vos dépôts. La 2.4.2 va probablement arriver sous quelques jours.

Source : Phoronix

❌