PinTheft l'explosion publique qui pourrait vous donner racine sur Arch Linux

Une nouvelle explosion publique a fait ressortir la fragilité du modèle de privilèges Linux : l'équipe de sécurité V12 a qualifié l'échec de Vol d'épingles et publié un test de concept qui permet à un utilisateur local de grimper racine sur les systèmes Arch Linux avec des conditions spécifiques remplies. Bien que l'erreur ait déjà été corrigée dans le noyau, la disponibilité du PoC rend le risque réel pour les machines non décalées ou mal configurées.

La vulnérabilité réside dans le chemin d'expédition à zéro du sous-système RDS (Sockets de données fiables). D'une manière générale, la fonction que les pages utilisateur "pinnea" peuvent perdre des références lorsqu'une exception de mi-opération se produit; cette double libération (double-libre) combinée avec l'interaction avec des tampons io _ fixes peut se terminer par une écrasement du cache des pages et, enfin, dans le contrôle de la mémoire capable d'atteindre un shell avec des privilèges élevés. V12 explique le vecteur technique et publie le code dans son dépôt, ce qui permet aux défenseurs de mieux comprendre l'exploitation et, malheureusement, aux attaquants de le recréer : l'explication et le PdC de V12.

Il est important de souligner que l'exploitation n'est pas banale. Il exige que le module RDS soit chargé, que io _uring soit disponible dans le noyau, la présence d'un binaire SUID lisible et l'architecture x86 _ 64 pour la charge utile incluse, ce qui réduit considérablement la surface d'attaque. V12 souligne que, parmi les distributions courantes testées, le module RDS n'est activé que par défaut sur Arch Linux, de sorte que la particularité de la configuration par défaut augmente le risque dans cette distribution particulière.

Le patch qui corrige l'échec a déjà été envoyé à l'arborescence du noyau; les administrateurs et les utilisateurs devraient prioriser la mise à jour du noyau aux versions disponibles contenant cette correction. Le patch original est disponible pour vérifier quelles lignes ont été modifiées et confirmer l'inclusion dans les versions du noyau dans: détails de patch à lore.kernel.org. Appliquer le patch ou la mise à jour à la version du noyau distribuée par son disque est la mesure finale.

Pour les systèmes qui ne peuvent pas être corrigés immédiatement, il y a une atténuation pratique: télécharger le module RDS et bloquer sa charge future en créant un fichier dans / etc / modprobe.d / qui empêche son insertion. Un exemple efficace est d'exécuter rmmod rds _ tcp rds et d'écrire dans / etc / modprobe.d / pinheft.conf lignes installer rds / bin / false et installer rds _ tcp / bin / false. Cette intervention empêche l'utilisation du vecteur RDS, mais elle doit être évaluée car elle peut désactiver les fonctionnalités réseau qui dépendent du module.

Au-delà du patch et de l'atténuation technique, l'apparition répétée d'erreurs d'escalade locale dans le noyau et la publication publique du PoC mettent en évidence une leçon pratique: réduire l'exposition à la surface de l'attaque. Il s'agit notamment d'examiner et de minimiser les binaires SUID, de désactiver les modules de noyau inutiles, de contrôler les paramètres de sécurité du système (p. ex. les politiques de seccomp et de grsecurity quand disponibles) et d'appliquer les principes les moins privilégiés dans les environnements multi-utilisateurs et les serveurs cloud.

Les organisations doivent aussi intégrer la détection et l'intervention : laisser des traces de tentatives d'exploitation peut faire la différence entre un incident confiné et une escalade. L'examen des registres du noyau, les audits d'accès et les alertes liées à l'activité, la charge inhabituelle des modules ou les avortements de processus peuvent aider à détecter les activités suspectes. Pour le contexte de la menace mondiale et d'autres vulnérabilités croissantes qui attirent l'attention, l'Agence de la CISA tient à jour des avertissements et des catalogues de vulnérabilités exploitées dans la nature; voir sa déclaration relative à la récente vague de LPES : avis de la CISA.

Enfin, compte tenu de la publication du PoC et de la rapidité avec laquelle le même type de défaillance a été révélé (DirtyDecrypt, DirtyCBC, Copy Fail, entre autres), ma recommandation pour les administrateurs et utilisateurs avancés est de prioriser la maintenance proactive: mettre à jour les correctifs de sécurité du noyau et de la distribution, vérifier et minimiser les modules et les binaires SUID, et appliquer une atténuation temporaire lorsqu'il n'est pas possible de stationner immédiatement. La transparence technique du patch et du PoC facilite la défense, mais réduit également le temps de grâce; l'action précoce est la clé.