PinTheft (PSA-2026-00022-1) — détection + mitigation

PinTheft est une chaîne d’élévation de privilèges locale combinant un double-free dans le module noyau Linux RDS (Reliable Datagram Sockets) et une corruption de fixed-buffer io_uring pour transformer tout utilisateur non privilégié en root. Publié sous PSA-2026-00022-1 le 2026-05-19 ; affecte tous les noyaux Proxmox actuels et la plupart des distributions Linux standard où les modules rds sont construits. Au moment de la rédaction, aucun noyau patché n’est dans les dépôts distro.

Comment monsys aide

Couche	Quoi
Inventaire	L’agent envoie /proc/modules à chaque cycle d’inventaire vers POST /api/v1/kernel-modules. Schéma 103.
Détection	Règle kernel_module_suspicious semée par tenant, matche rds, rds_tcp, rds_rdma contre le set chargé. Les hits produisent une ligne detected_events avec severity critical.
Mitigation	Emergency Action pintheft_mitigate déclenchée par l’opérateur, gardée par TOTP. Le wrapper dépose /etc/modprobe.d/pintheft.conf (avec install <mod> /bin/false + blacklist) et fait rmmod sur tout module RDS chargé. Idempotent.

Selon le principe human-in-the-loop, monsys ne décharge jamais de modules automatiquement. La détection se déclenche ; l’opérateur revoit l’évènement de détection ; l’opérateur signe une EAT via TOTP ; l’agent exécute.

Pourquoi cette règle par défaut est sûre

Sur Ubuntu 24.04, le blacklist-rare-network.conf fourni neutralise déjà l’auto-load via socket(AF_RDS, ...) grâce à alias net-pf-21 off. Un attaquant non privilégié ne peut donc PAS charger le module via le truc syscall — mais un cron malveillant, un installateur buggué, ou un admin qui lance modprobe rds pour des raisons indépendantes le peut. La détection couvre tous ces cas en sondant /proc/modules. La mitigation ferme le chemin install que blacklist-rare-network.conf ne traite pas.

Note : il n’est pas nécessaire d’attendre un noyau patché pour cette mitigation — RDS n’est pas utilisé sur quasi tous les serveurs production belges/UE que nous avons audités. Si l’opérateur a besoin de RDS pour des raisons légitimes (certains clusters IBM DB2 RAC et une poignée de setups HPC), laissez la détection active et acceptez l’alerte comme exception informée.

Config de la règle de détection

La ligne seed (par tenant, insérée automatiquement à l’application de mig 103) :

{
  "module_names": ["rds", "rds_tcp", "rds_rdma"],
  "advisory":     "PSA-2026-00022-1",
  "description":  "rds + io_uring double-free chain → local privilege escalation. Unload and blacklist if unused."
}

La même rule_kind (kernel_module_suspicious) sera réutilisée pour les futures divulgations de LPE noyau — seul module_names change par CVE.

Forme de l’EAT

{
  "kind": "pintheft_mitigate"
}

Sans paramètre : cette action blackliste toujours rds, rds_tcp, rds_rdma. Le wrapper sur /usr/local/sbin/monsys-pintheft-mitigate est le seul chemin avec sudo NOPASSWD ; il écrit /etc/modprobe.d/pintheft.conf et appelle rmmod sur chaque module chargé. La sortie (stdout + stderr) est capturée et renvoyée au hub comme résultat de l’EAT pour le journal d’audit.

Vérifier que la mitigation a fonctionné

Après que l’EAT a abouti :

lsmod | grep -E '^rds|^rds_tcp|^rds_rdma'   # doit être vide
sudo modprobe -nv rds                        # devrait afficher "install /bin/false"
cat /etc/modprobe.d/pintheft.conf             # lignes blacklist + install

Le cycle d’inventaire suivant ré-envoie /proc/modules. RDS absent, la règle de détection ne match plus, et la ligne detected_events ouverte précédente est dédupliquée en-ligne (fenêtre 24h) jusqu’à ce que l’opérateur l’acquitte via le dashboard.

Mapping de conformité

ISO 27001 A.8.7 (Protection contre les logiciels malveillants) — évaluée automatiquement en comptant les évènements kernel_module_suspicious non acquittés par tenant. La ligne de contrôle a été ajoutée à compliance_framework_controls dans mig 103.