Qu'est-ce que Copy Fail ?

CVE-2026-31431 (CVSS 7.8) est un défaut logique dans l'interface socket AEAD du noyau Linux (AF_ALG) découvert en 2026. La vulnérabilité permet à tout utilisateur local non privilégié d'élever ses privilèges à root en quelques secondes.

Détails techniques

• Composant affecté : module noyau algif_aead (interface crypto AF_ALG)
• Type de vulnérabilité : défaut logique dans la gestion des opérations de copie
• Vecteur d'attaque : local
• Privilèges requis : aucun (utilisateur non privilégié)
• Interaction utilisateur : aucune
• Impact : compromission totale du système (accès root)

Systèmes affectés

Versions du noyau : noyau Linux >= 4.10 (publié en 2017)

Distributions affectées :

• Red Hat Enterprise Linux 7, 8, 9
• CentOS 7, 8, 9 (et Stream)
• Fedora (toutes les versions actuellement prises en charge)
• Ubuntu 17.04 et versions ultérieures
• Debian 9 (Stretch) et versions ultérieures
• SUSE Linux Enterprise 12, 15

Remarque : toute distribution Linux avec un noyau 4.10 ou plus récent est potentiellement vulnérable.

Pourquoi c'est important

Cette vulnérabilité est particulièrement dangereuse car :

1. Aucun privilège requis - n'importe quel compte utilisateur peut l'exploiter
2. Élévation instantanée - accès root en quelques secondes
3. Impact étendu - affecte plus de 7 ans de versions du noyau
4. Exécution locale - aucun accès distant requis, mais les attaquants qui obtiennent un premier accès peuvent immédiatement élever leurs privilèges
5. Exploitation active - des exploits publics sont disponibles

Impact dans le monde réel

Une fois qu'un attaquant dispose d'une forme quelconque d'accès local (SSH, shell web, évasion de conteneur, etc.), il peut :

• Prendre le contrôle total du système
• Installer des portes dérobées persistantes
• Accéder aux données sensibles
• Pivoter vers d'autres systèmes du réseau
• Déployer des ransomwares ou des cryptomineurs

Remédiations disponibles

En attendant les correctifs du noyau fournis par les éditeurs, plusieurs stratégies d'atténuation sont disponibles. cfDr les implémente toutes, avec des recommandations intelligentes basées sur la configuration de votre système.

Comprendre les niveaux de protection

Toutes les remédiations ne se valent pas. Voici ce que vous devez savoir :

Approche recommandée : défense en profondeur

Recommandation par défaut de cfDr : Niveau 3 (liste noire de modules + SELinux)

Cela fournit deux couches de protection indépendantes :``` ┌─────────────────────────────────────────────────┐ │ Layer 1: Module Blacklist │ │ • Prevents modprobe algif_aead │ │ • Persists across reboots │ │ • CAN be bypassed by malicious root (insmod) │ ├─────────────────────────────────────────────────┤ │ Layer 2: SELinux Policy │ │ • Blocks AF_ALG socket() at syscall level │ │ • Works even if module is loaded │ │ • CANNOT be bypassed from userspace │ │ • Covers user_t, unconfined_t (majority cases) │ └─────────────────────────────────────────────────┘

Result: If either layer fails, the other still protects

Cependant, cela est acceptable car :

1. La vulnérabilité cible l'élévation de privilèges (non privilégié → root)
2. Si un attaquant possède déjà root, il peut exploiter directement sans charger le module
3. La liste noire de modules protège contre le vecteur d'attaque principal

Stratégie de protection complète

Pour une protection complète et non contournable, vous avez besoin de :

Liste noire de modules + au moins l'un des éléments suivants :

• Politique SELinux (recommandée pour Enterprise Linux)
• Filtres seccomp systemd (protection par service)
• Programme eBPF LSM (RHEL 9+ uniquement, à l'échelle du système)

Référence des indicateurs d'atténuation

cfDr utilise des indicateurs binaires pour activer plusieurs atténuations :

Calcul des indicateurs : 1 (liste noire) + 2 (SELinux) + 4 (seccomp) + 8 (eBPF) = somme

Lacunes de couverture à connaître

Protection SELinux :

• Couvre uniquement les domaines spécifiés dans la politique : user_t, unconfined_t, httpd_t, postgresql_t, mysqld_t
• Les processus exécutés dans d'autres domaines SELinux peuvent ne pas être protégés
• En pratique, user_t et unconfined_t couvrent la grande majorité des scénarios d'attaque

Protection seccomp systemd :

• Protège uniquement les services explicitement configurés
• La configuration par défaut couvre : httpd, nginx, postgresql, mariadb, redis, memcached
• Les processus en dehors de ces services ne sont pas protégés

Protection eBPF LSM :

• Nécessite un noyau 5.7+ (RHEL 9, Fedora 34+)
• La complexité exige une expertise pour une mise en œuvre correcte
• Peut fournir une protection complète à l'échelle du système si elle est correctement configurée

Méthodologie de détection

Comment cfDr détecte la vulnérabilité

cfDr effectue une évaluation complète sur plusieurs dimensions :

1. Vérification de la version du noyau```bash

uname -r

• Vérifie si le module algif_aead existe dans le noyau
• Contrôle l'emplacement et les métadonnées du module

3. État de chargement du module```bash

lsmod | grep algif_aead

• Identifie les sockets AF_ALG actifs
• Indique une exploitation active potentielle

5. Détection des mesures d’atténuation existantes

Liste noire de modules :```bash grep -E "blacklist algif_aead|install algif_aead" /etc/modprobe.d/*.conf

systemd seccomp :```bash systemctl show | grep RestrictAddressFamilies

Comment fonctionne cfDr

Architecture

cfDr est conçu comme un rôle Ansible moderne avec plusieurs points d'entrée de playbook :``` cfDr/ ├── roles/ │ └── cve_2026_31431/ # Main role │ ├── tasks/ │ │ ├── main.yml # Role orchestration │ │ ├── assessment.yml # Vulnerability detection │ │ ├── remediation_module_blacklist.yml │ │ ├── remediation_selinux.yml │ │ ├── remediation_seccomp.yml │ │ ├── remediation_ebpf.yml │ │ ├── reporting.yml # Status reporting │ │ └── inventory_update.yml # Inventory generation │ ├── templates/ # Config file templates │ ├── defaults/ # Default variables │ └── handlers/ # Service restarts, etc. ├── quickstart.yml # Simplest usage ├── sample_playbook.yml # Multiple examples └── cve_2026_31431_playbook.yml # Full-featured playbook

Mode de remédiation (apply_remediation=true)```

1-8. [Same as Assessment Mode] ↓ 9. Apply Module Blacklist (if flag 1) • Unload module if loaded • Create blacklist config • Update initramfs/initrd • Verify blacklist works ↓ 10. Apply SELinux Policy (if flag 2) • Install policy packages • Compile policy module • Install policy • Verify policy active ↓ 11. Apply systemd seccomp (if flag 4) • Create drop-in files • Reload systemd • Restart services • Verify filters active ↓ 12. Apply eBPF LSM (if flag 8) • Compile eBPF program • Load into kernel • Verify program attached ↓ 13. Re-assess protection status ↓ 14. Generate reports ↓ 15. Create summary

3. Met à jour initramfs/initrd pour persister après les redémarrages :
   • Debian/Ubuntu : update-initramfs -u
   • RHEL/Fedora : dracut -f
4. Vérifie que le module ne peut pas être chargé via modprobe

Protection : Immédiate, aucun redémarrage requis Persistance : Survit aux redémarrages et aux mises à jour du noyau

Politique SELinux (Drapeau 2)

Ce qu'elle fait :

1. Installe les paquets requis :
   • policycoreutils
   • policycoreutils-python-utils
   • selinux-policy-devel
   • checkpolicy
2. Crée un module de politique SELinux refusant la création de sockets AF_ALG
3. Compile la politique à l'aide du système de construction SELinux
4. Installe le module de politique : semodule -i cve_2026_31431_af_alg_deny.pp
5. Vérifie que la politique est active

Domaines protégés (par défaut) :

• user_t - Processus utilisateur standard
• unconfined_t - Processus non confinés
• httpd_t - Serveur web Apache
• postgresql_t - Base de données PostgreSQL
• mysqld_t - Base de données MySQL/MariaDB

Protection : Bloque au niveau de la couche LSM, ne peut pas être contournée Persistance : La politique survit aux redémarrages

systemd seccomp (Drapeau 4)

Ce qu'il fait :

1. Crée des fichiers drop-in systemd : /etc/systemd/system/<service>.service.d/90-cve-2026-31431-block-af-alg.conf
2. Ajoute la directive RestrictAddressFamilies=~AF_ALG
3. Recharge le démon systemd
4. Redémarre les services concernés
5. Vérifie que les filtres sont actifs

Services protégés (par défaut) :

• httpd, nginx - Serveurs web
• postgresql, mariadb - Bases de données
• redis, memcached - Serveurs de cache

Protection : Bloque la création de sockets au niveau des appels système par service Persistance : Survit aux redémarrages et aux mises à jour des services

eBPF LSM (Drapeau 8)

Ce qu'il fait :

1. Compile un programme eBPF pour bloquer la création de sockets AF_ALG
2. Charge le programme dans le noyau
3. L'attache aux hooks LSM
4. Vérifie que le programme est actif

Exigences :

• Noyau 5.7+ avec CONFIG_BPF_LSM=y
• RHEL 9, Fedora 34+, ou noyau compilé sur mesure

Protection : Politique dynamique et programmable à l'échelle du système Persistance : Nécessite un service système pour recharger au démarrage

Génération d'inventaire

cfDr peut générer des fichiers d'inventaire prêts à l'emploi contenant uniquement les hôtes vulnérables :

Fichiers générés :``` inventory_output/ ├── vulnerable_hosts.yml # YAML inventory ├── vulnerable_hosts.ini # INI inventory ├── group_vars_vulnerable_hosts.yml # Group variables └── host_vars/ ├── host1.yml # Per-host details └── host2.yml

Ce qui pourrait être affecté (cas limites rares)

Selon l'analyse de R-fx Networks :

« Pour la plupart des environnements HPC, cela ne cassera rien – AF_ALG est une porte d'entrée côté utilisateur vers la crypto du noyau que presque rien n'utilise réellement. »

Seules ces configurations extrêmement rares pourraient être affectées :

1. OpenSSL avec le moteur afalg explicitement activé

PAS par défaut sur RHEL. Le moteur afalg doit être explicitement configuré :```bash

Check if afalg engine is enabled (rare)

openssl engine afalg

If this returns "afalg is not available", you're safe

Résultat attendu : Tous les services continuent de fonctionner normalement.

Consensus de la communauté professionnelle de la sécurité

Plusieurs organisations de sécurité faisant autorité confirment notre évaluation :

CERT-EU (30 avril 2026) :

« Les builds dm-crypt / LUKS, kTLS, IPsec, SSH et OpenSSL / GnuTLS par défaut ne dépendent pas d'AF_ALG »

Sysdig (29 avril 2026) :

Documente que les opérations cryptographiques standard utilisent des API du noyau, et non des sockets AF_ALG

R-fx Networks (2 mai 2026) :

« Les charges de travail d'hébergement n'utilisent pas légitimement AF_ALG, ce qui rend son désactivation sûre comme mesure d'atténuation sans impact sur les services de production »

HPCsec (30 avril 2026) :

« Pour la plupart des environnements HPC, cela ne cassera rien – AF_ALG est une porte d'entrée côté espace utilisateur vers la cryptographie du noyau que presque personne n'utilise réellement »

Recommandation pour le déploiement en production

Pour les environnements RHEL/CentOS/Fedora standard :

1. ✅ Déployez le drapeau cfDr 3 immédiatement - Impact opérationnel nul
2. ✅ Tous les services critiques continueront de fonctionner - Vérifié par la communauté de la sécurité
3. ✅ Aucune modification d'application requise - Les chemins cryptographiques standard ne sont pas affectés
4. ✅ Surveillez Red Hat pour les correctifs du noyau - Mais n'attendez pas pour atténuer
5. ✅ Conservez la défense en profondeur après le correctif - Couche de sécurité supplémentaire sans coût

Matrice de décision :

Résumé

Les mesures correctives de cfDr sont sûres pour tous les déploiements RHEL standard. Le module algif_aead et l'interface socket AF_ALG ne sont pas utilisés par aucune cryptographie système critique sur les systèmes Enterprise Linux.

Ce que cela signifie :

• ✅ Votre chiffrement de disque (LUKS) continue de fonctionner
• ✅ Vos VPN (IPsec) continuent de fonctionner
• ✅ Vos connexions SSH continuent de fonctionner
• ✅ Vos serveurs web (HTTPS) continuent de fonctionner
• ✅ Vos bases de données continuent de fonctionner
• ✅ Tous les systèmes d'authentification continuent de fonctionner

Le seul risque théorique concerne les applications personnalisées explicitement programmées pour utiliser les sockets AF_ALG - un scénario si rare que plusieurs organisations de sécurité ont indépendamment confirmé qu'il est sûr de bloquer AF_ALG dans les environnements d'entreprise.

Flux de travail recommandé

Flux de travail d'entreprise standard

Ce flux de travail équilibre rigueur et sécurité opérationnelle :

Étape 1 : Évaluation initiale (lecture seule)```bash

Scan all hosts without making changes

ansible-playbook -i inventory quickstart.yml

Étape 2 : Générer l’inventaire des vulnérabilités```bash

Create inventory of vulnerable hosts with recommendations

ansible-playbook -i inventory quickstart.yml -e generate_inventory=true -e inventory_output_dir=./vulnerable_hosts

Étape 3 : Tester la remédiation hors production```bash

Apply to test/dev hosts first

ansible-playbook -i vulnerable_hosts/vulnerable_hosts.yml cve_2026_31431_playbook.yml
-e apply_remediation=true
--limit 'dev*:test*'

Applications de test :

• Vérifier le fonctionnement des services critiques
• Contrôler la fonctionnalité des applications
• Surveiller les journaux pour détecter les problèmes

Étape 4 : Remédiation en production (par étapes)```bash

Apply to production in stages

Stage 1: Web tier

ansible-playbook -i vulnerable_hosts/vulnerable_hosts.yml cve_2026_31431_playbook.yml
-e apply_remediation=true
--limit 'web*'

Stage 2: Application tier

ansible-playbook -i vulnerable_hosts/vulnerable_hosts.yml cve_2026_31431_playbook.yml
-e apply_remediation=true
--limit 'app*'

Stage 3: Database tier (most critical)

ansible-playbook -i vulnerable_hosts/vulnerable_hosts.yml cve_2026_31431_playbook.yml
-e apply_remediation=true
--limit 'db*'

Document :

• Enregistrez quels hôtes ont été corrigés
• Notez tout problème rencontré
• Mettez à jour les enregistrements de gestion des changements

Résultat final attendu :``` CVE-2026-31431 Summary Report

Total hosts scanned: 50 Vulnerable hosts: 0

All hosts protected with defense-in-depth mitigations

Utilisez cette approche lorsque :

• Une exploitation active est détectée
• Des systèmes critiques sont en danger immédiat
• Le temps est plus critique que le processus

Attention : Cela applique des mesures d'atténuation à TOUS les hôtes vulnérables simultanément. Surveillez de près.

Workflow de surveillance continue

Pour la conformité continue et la détection de nouveaux systèmes :```bash

Weekly automated scan

0 2 * * 0 ansible-playbook -i inventory quickstart.yml -e generate_inventory=true

Alert on new vulnerabilities

(integrate with monitoring system)

Workflow de vérification

Après la remédiation, vérifiez la protection :```bash

On remediated host:

sudo lsmod | grep algif_aead

Should return nothing (module not loaded)

sudo modprobe algif_aead

Should fail: "modprobe: ERROR: could not insert 'algif_aead'"

cat /etc/modprobe.d/blacklist-algif_aead-cve-2026-31431.conf

Should show blacklist configuration

Check SELinux policy

sudo semodule -l | grep cve_2026_31431

Should show: cve_2026_31431_af_alg_deny

Check seccomp (for services)

systemctl show httpd | grep RestrictAddressFamilies

Should show: RestrictAddressFamilies=~AF_ALG

Utilisation avec un inventaire personnalisé```bash

Assess with your inventory

ansible-playbook -i /path/to/your/inventory quickstart.yml

Remediate vulnerable hosts

ansible-playbook -i /path/to/your/inventory quickstart.yml
--limit vulnerable_hosts
-e apply_remediation=true

Configuration avancée

Personnalisation des indicateurs d’atténuation

Remplacez les atténuations par défaut pour chaque exécution de playbook :```bash

Module blacklist only

ansible-playbook quickstart.yml -e apply_remediation=true -e mitigation_flags=1

SELinux only

ansible-playbook quickstart.yml -e apply_remediation=true -e mitigation_flags=2

Module blacklist + SELinux (default recommended)

ansible-playbook quickstart.yml -e apply_remediation=true -e mitigation_flags=3

Enhanced: Blacklist + SELinux + seccomp

ansible-playbook quickstart.yml -e apply_remediation=true -e mitigation_flags=7

Maximum: All mitigations (RHEL 9+ only)

ansible-playbook quickstart.yml -e apply_remediation=true -e mitigation_flags=15

Personnalisation des services seccomp

Modifiez roles/cve_2026_31431/defaults/main.yml :```yaml

Add additional services to protect

seccomp_protected_services:

• httpd
• nginx
• postgresql
• mariadb
• redis
• memcached
• your-custom-service # Your service

Utilisation des modèles de playbook d'exemple

Le fichier sample_playbook.yml contient plusieurs exemples :```yaml

Example 1: Assessment only

• hosts: all roles:
  • cve_2026_31431

Example 2: Module blacklist only

• hosts: all vars: apply_remediation: true mitigation_flags: 1 roles:
  • cve_2026_31431

Example 3: Recommended (Blacklist + SELinux)

• hosts: all vars: apply_remediation: true mitigation_flags: 3 roles:
  • cve_2026_31431

4. Surveillance automatisée : ```bash

   Install Red Hat Security Advisories plugin for yum

   sudo yum install yum-plugin-security

   Check for security updates

   sudo yum updateinfo list security

   Check specifically for kernel updates

   sudo yum updateinfo list security kernel

   root@kitploit:~

Ce qu'il faut rechercher :

• RHSA (Red Hat Security Advisory) pour le noyau
• Titre de l'avis contenant « CVE-2026-31431 »
• Versions RHEL concernées correspondant à votre environnement

Exemple de format d'avis :``` RHSA-2026:XXXX - Important: kernel security update Severity: Important CVEs: CVE-2026-31431 Affected Products: RHEL 7, 8, 9

Ubuntu

Source principale : Avis de sécurité Ubuntu

• Base de données USN : https://ubuntu.com/security/notices
• Suivi des CVE : https://ubuntu.com/security/CVE-2026-31431

Méthodes de notification :```bash

Subscribe to security announcements

Visit: https://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce

Check for security updates

sudo apt update sudo apt list --upgradable | grep security

Ubuntu Security Notices tool

sudo apt install ubuntu-security-tools usn list --cve CVE-2026-31431

SUSE / openSUSE

Source principale : SUSE Security

• Mises à jour de sécurité : https://www.suse.com/support/update/
• Base de données CVE : https://www.suse.com/security/cve/CVE-2026-31431.html

Méthodes de notification :```bash

Check for security patches

sudo zypper list-patches --category security

Specific CVE check

sudo zypper info --cve CVE-2026-31431

Script de surveillance automatisée des correctifs

Créez un script de surveillance pour votre environnement :```bash #!/bin/bash

check-cve-2026-31431-patch.sh

Monitors for CVE-2026-31431 kernel patches

DISTRO=$(grep ^ID= /etc/os-release | cut -d= -f2 | tr -d '"')

case $DISTRO in rhel|centos|rocky|alma) yum updateinfo list security kernel 2>/dev/null | grep -i CVE-2026-31431 ;; fedora) dnf updateinfo list security kernel 2>/dev/null | grep -i CVE-2026-31431 ;; ubuntu|debian) apt-get update -qq apt-cache show linux-image-$(uname -r) | grep CVE-2026-31431 ;; sles|opensuse*) zypper info --cve CVE-2026-31431 kernel-default ;; esac

Check Red Hat Security Data API

curl -s "https://access.redhat.com/labs/securitydataapi/cve/CVE-2026-31431.json" |
jq -r '.affected_release[] | select(.package | startswith("kernel")) | "(.product_name): (.advisory) - (.package)"'

Que faire lorsque des correctifs sont publiés

1. Vérifier la disponibilité du correctif : ```bash

   Check your distribution's update mechanism

   sudo yum check-update kernel # RHEL/CentOS/Fedora sudo apt update && apt list --upgradable linux-image-* # Ubuntu/Debian

   root@kitploit:~

2. Examiner les notes de version :

   • Lire l'avis du fournisseur pour les instructions d'installation
   • Vérifier les problèmes connus ou les prérequis
   • Vérifier les numéros de version du noyau

3. Tester hors production : ```bash

   Apply kernel update to test systems first

   sudo yum update kernel # RHEL/CentOS/Fedora sudo apt upgrade linux-image-* # Ubuntu/Debian sudo reboot

   root@kitploit:~

4. Vérifier l’efficacité du correctif : ```bash

   After reboot, verify kernel version

   uname -r

   Run cfDr assessment to confirm patch

   ansible-playbook -i inventory quickstart.yml

   root@kitploit:~

5. Planifier le déploiement en production :

   • Planifier les fenêtres de maintenance
   • Échelonner les mises à jour du noyau
   • Prévoir les redémarrages/reboots des services

6. Supprimer les mesures d'atténuation temporaires (facultatif) : ```bash

   After patching, temporary mitigations can be removed

   However, defense-in-depth recommends keeping them

   If you choose to remove:

   sudo rm /etc/modprobe.d/blacklist-algif_aead-cve-2026-31431.conf sudo semodule -r cve_2026_31431_af_alg_deny # SELinux policy

   Remove seccomp drop-in files

   Update initramfs/initrd

   root@kitploit:~

Recommandation : Même après l'application du correctif du noyau, envisagez de conserver les mesures de défense en profondeur en place comme protection contre de futures vulnérabilités.

Support et Contributions

Signaler des Problèmes

Vous avez trouvé un bug ou souhaitez proposer une fonctionnalité ?

1. Vérifiez les problèmes existants : https://github.com/parmstro/cfDr/issues
2. Créez un nouveau problème : Incluez :
   • La version de cfDr
   • La version d'Ansible
   • Le système d'exploitation cible et sa version
   • Les messages d'erreur complets
   • Les étapes pour reproduire le problème

Contribuer

Nous accueillons volontiers les contributions ! Consultez docs/CONTRIBUTORS.md pour :

• Comment contribuer au code
• Les améliorations de documentation
• Les tests et rapports de bugs
• Les suggestions de fonctionnalités

Obtenir de l'Aide

• Problèmes : https://github.com/parmstro/cfDr/issues
• Discussions : https://github.com/parmstro/cfDr/discussions

Contributeurs

cfDr est construit sur l'expertise collective des professionnels de la sécurité :

• Paul Armstrong (@parmstro) - Chef de projet, implémentations de la liste noire de modules et de seccomp
• Anthony Green (@atgreen) - Implémentation de l'atténuation eBPF LSM
• Greg Procunier (@gprocunier) - Implémentation de l'atténuation de la politique SELinux
• Claude Sonnet 4.5 - Assistance au développement, documentation et recherche

Consultez docs/CONTRIBUTORS.md pour les détails complets des contributions.

Licence

Ce projet est fourni sous la licence MIT à des fins d'évaluation des vulnérabilités et de remédiation.

Consultez LICENSE pour plus de détails.

Avertissement

IMPORTANT : Cet outil fournit des atténuations temporaires en attendant les correctifs du noyau fournis par les vendeurs. Ces atténuations réduisent considérablement les risques mais peuvent ne pas offrir une protection complète dans tous les scénarios.

cfDr est fourni « tel quel » sans garantie. Toujours :

• Tester d'abord hors production
• Comprendre la couverture de protection et ses lacunes
• Surveiller les canaux des vendeurs pour les correctifs officiels
• Appliquer les correctifs des vendeurs lorsqu'ils sont disponibles
• Maintenir la défense en profondeur même après l'application des correctifs

Les contributeurs et mainteneurs de cfDr ne sont pas responsables des dommages ou pertes de données résultant de l'utilisation de cet outil.

Dernière mise à jour : 2026-05-02T23:30:00Z