Aucun des deux bugs n'est totalement fiable à lui seul — le chemin ESP nécessite la possibilité de créer un espace de noms utilisateur (ce que l'AppArmor d'Ubuntu bloque), et le chemin RxRPC nécessite que rxrpc.ko soit chargé (ce que la plupart des distributions ne font pas par défaut). Ensemble, ils couvrent mutuellement leurs angles morts, rendant la chaîne exploitable sur pratiquement toutes les distributions majeures.

Un proof-of-concept public est disponible. Considérez qu'il est déjà utilisé activement.

Ce que fait ce script

Il vérifie les conditions qui rendent l'exploitation possible sur votre système, et vous indique précisément pourquoi vous êtes exposé — pas seulement un oui ou un non.

Il ne corrigera rien. Il n'exploitera rien. Il vous dit simplement la vérité sur votre système.

Prérequis

• Python 3.6+
• Aucune dépendance externe — bibliothèque standard uniquement
• Aucun accès root requis (volontairement — nous vérifions ce qu'un attaquant non privilégié peut voir)

Utilisation

C'est tout. Sortie codée par couleurs, raisons spécifiques pour chaque constat, et un résumé de remédiation à la fin.

Capture d'écran

[]

Corriger le problème

Le vrai correctif consiste à patcher votre noyau. Consultez les avis de sécurité de votre distribution :

En attendant (ou si les correctifs ne sont pas encore disponibles pour votre distribution), blacklistez les modules vulnérables :

⚠️ Avant de faire cela :

• Blacklister esp4/esp6 cassera les tunnels IPsec (strongSwan, Libreswan, WireGuard n'est pas affecté). Ne l'appliquez pas sur les passerelles VPN.
• Blacklister rxrpc cassera les clients du système de fichiers distribué AFS. Presque personne ne l'utilise — mais vérifiez d'abord.

Important : si votre système a pu être ciblé avant l'application de l'atténuation, l'exploit peut modifier des binaires dans le cache de pages sans toucher au disque. Les outils d'intégrité des fichiers (Tripwire, AIDE) qui vérifient les sommes de contrôle sur disque ne verront rien d'anormal. Un redémarrage vide le cache de pages et restaure l'état sur disque.

Comment ça fonctionne (version courte)

Les deux bugs se trouvent dans les chemins rapides de déchiffrement en place du noyau. Lorsqu'un tampon de socket transporte des fragments paginés qui ne sont pas privés au noyau — par exemple, des pages de tube attachées via splice() ou sendfile() — les chemins de réception ESP et RxRPC déchiffrent directement sur ces pages adossées à l'externe au lieu de copier d'abord.

Un attaquant peut diriger une page du cache de /usr/bin/su (ou de tout autre fichier lisible) vers l'un de ces chemins de déchiffrement, en utilisant sa propre clé afin que la « sortie déchiffrée » soit les octets de son choix. Le noyau écrit ces octets directement dans la copie en cache en mémoire de su. Le fichier sur disque est intact. Le noyau ne marque jamais la page comme sale.

À partir de ce moment, chaque processus qui exécute su lance la version de l'attaquant — jusqu'à drop_caches ou un redémarrage.

La variante ESP (cac2661c53f3) et la variante RxRPC (2dc334f1a63a) partagent le même point de chute mais ont des prérequis différents qui s'annulent mutuellement, rendant la chaîne fiable sur toutes les configurations majeures.

Pour l'analyse technique complète, voir V4bel/dirtyfrag.

Chronologie de divulgation

Crédit : Hyunwoo Kim (@v4bel) pour la recherche originale, la divulgation et le PoC.

Avertissement

Détection uniquement. Pointez-le sur des systèmes que vous êtes autorisé à évaluer.