Les vulnérabilités du noyau Linux ne font pas l’objet d’une notification préalable aux distributions

• CopyFail, une vulnérabilité d’élévation locale de privilèges du noyau Linux, fait récemment partie de la catégorie la plus grave des vulnérabilités du noyau de type « make-me-root » (qui permettent de transformer un utilisateur ordinaire en root)
• Cette vulnérabilité a été introduite par un commit spécifique de la version 4.14 du noyau, ce qui coïncide avec le moment où l’optimisation in-place a été ajoutée au module authencesn exploité par CopyFail
• Le correctif a été intégré dans les noyaux 6.18.22, 6.19.12 et 7.0, et les versions 6.18.22 et 6.19.12 ont été publiées le 11 avril avec le correctif rétroporté
• Mais ce correctif n’est toujours pas inclus dans les noyaux Longterm largement utilisés (6.12, 6.6, 6.1, 5.15, 5.10), et il n’a pas non plus été repéré dans l’upstream stable queue
  • Comme le problème a été introduit en 2017, il faut aussi vérifier si ces anciens noyaux Longterm sont eux aussi concernés
• Le patch de correction ne s’applique pas proprement aux anciens noyaux, et à cause de plusieurs changements d’API, il est difficile de procéder à un rétroportage avec assurance
• Dans les environnements qui exigent une réponse immédiate, il est possible d’appliquer à titre provisoire un patch désactivant le module authencesn d’IPSec ; même sans être spécialiste d’IPSec, cela reste « un choix imparfait mais moins mauvais »
• En d’autres termes, le problème structurel tient au processus même de divulgation des vulnérabilités du noyau Linux :
  • À moins que la personne qui signale la vulnérabilité n’en informe directement la mailing list linux-distros (canal privé réunissant les équipes sécurité des distributions), aucune notification préalable n’est transmise aux différentes distributions
  • Dans le cas de CopyFail, aucun heads-up préalable n’a été envoyé via la mailing list linux-distros
  • Autrement dit, les équipes sécurité des principales distributions comme Ubuntu, RHEL et SUSE n’ont pas eu l’occasion de préparer un correctif avant la divulgation publique

[unsure4000]

L’article de blog est un peu infantilisant, mais je pense qu’au-delà du simple fait d’être agaçant, le problème tient davantage à une défaillance systémique.

[GN⁺]

Avis sur Hacker News

• Sam James, l’auteur du billet lié, est développeur Gentoo
  Quoi qu’il en soit, c’était pratiquement catastrophique, et publier un exploit avant que les distributions ne diffusent un correctif a été extrêmement irresponsable
  Impossible de savoir combien d’hébergeurs mutualisés ont été compromis à cause de cela
  Il est également inquiétant qu’il semble ne pas y avoir de communication entre la kernel security team et les mainteneurs de distributions
  On s’attend à ce que la première prévienne les seconds, mais en pratique tout semble reposer sur la personne qui a découvert la faille

  • Je n’ai pas de problème avec le principe d’une divulgation 30 jours après l’intégration du correctif
    À titre de comparaison, Google Project Zero applique aussi une politique similaire de type « 90+30 » : https://projectzero.google/vulnerability-disclosure-policy.h...
    Le vrai problème, c’est l’absence de canal de communication entre la kernel security team et les mainteneurs de distributions
    La personne qui découvre la vulnérabilité ne devrait pas avoir la responsabilité de notifier séparément tous les downstream
    L’équipe kernel aurait dû informer la liste des responsables sécurité des distributions de l’importance du correctif et du calendrier de publication à 30 jours
  • Cette divulgation relevait davantage du marketing que de la sécurité
    La page de publication contient aussi des formules comme « Is your software AI-era safe? », « Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem », « [Try Xint Code] »
    C’est une manière de rendre le produit plus séduisant à mesure que la confusion augmente
  • En tant qu’utilisateur et administrateur, je ne suis pas d’accord avec l’idée que cela ait été « très irresponsable »
    L’expression Responsible Disclosure, comme « Secure Boot », est une formule linguistiquement très bien emballée, et en pratique elle semble surtout servir à protéger la réputation des entités intermédiaires — entreprises ou fondations — entre mon ordinateur et moi
    Elles semblent moins intéressées par le fait que ma machine individuelle soit vulnérable que par l’idée d’empêcher qu’on dise « RHEL est vulnérable » ou « Ubuntu est vulnérable »
    Les vulnérabilités existent de toute façon, donc je préfère avoir la possibilité d’en connaître le risque et de le réduire plutôt que d’attendre simplement une correction silencieuse
    À mes yeux, seule une divulgation immédiate n’est pas irresponsable
  • Indépendamment de la position qu’on adopte sur la procédure de divulgation, si un hébergeur s’est fait compromettre à cause de ça, c’est qu’il était déjà dans une configuration vouée à perdre
    Faire tourner des workloads de locataires qui ne se font pas confiance sous un kernel partagé unique n’est pas acceptable
    Les LPE du kernel ne sont pas rares, et ici celle-ci était surtout particulièrement simple et portable, tandis que la capacité offensive brute relève presque de la commodité CNE
  • Le kernel Linux n’est pas adapté comme frontière de sécurité
    Pour faire de l’hébergement mutualisé sans se faire compromettre, il faut utiliser d’autres moyens, comme gVisor ou des VM Firecracker
    Le principal système important qui l’utilise comme frontière de sécurité est Android, mais cela y est atténué par l’approbation utilisateur à l’installation des APK, des politiques SELinux et seccomp strictes, ainsi que le hardening de GrapheneOS
    Dans ce cas aussi, les atténuations ont fonctionné : https://discuss.grapheneos.org/d/35110-grapheneos-is-protect...

• Je ne comprends pas pourquoi on dit des choses du type « pour une vulnérabilité du kernel Linux, les distributions ne reçoivent pas de préavis à moins que le rapporteur ne contacte directement la ML linux-distros »
  Dire que le rapporteur doit coordonner directement avec les distributions suppose une connaissance approfondie du projet Linux
  L’auteur du signalement ne devrait pas avoir la responsabilité de travailler directement avec tous les consommateurs downstream du kernel Linux
  À ce compte-là, faudrait-il aussi prévenir directement tous les fabricants qui utilisent Linux dans leurs équipements ?
  À mon avis, le rapporteur a déjà fait ce qu’il fallait en signalant de manière responsable au projet Linux et en attendant que le correctif soit intégré
  Il devrait exister, au sein du projet Linux, des personnes dotées de l’autorité et de la responsabilité nécessaires pour gérer les vulnérabilités de sécurité, y compris la notification aux distributions downstream

  • C’est d’autant plus vrai qu’il est explicitement demandé au rapporteur de ne pas prévenir d’abord les équipes des distributions
    https://docs.kernel.org/process/security-bugs.html
    As such, the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL a fix is accepted by the affected code’s maintainers and you have read the distros wiki page above and you fully understand the requirements that contacting “linux-distros” will impose on you and the kernel community.
  • Le rapporteur a bien eu le temps de vérifier et de mentionner sur son site des distributions précises comme Ubuntu/RHEL/SUSE
    Il aurait au minimum été responsable de prévenir les équipes sécurité de ces distributions
  • Il est difficile de considérer comme raisonnable le fait que le rapporteur ait créé un site web nommant explicitement Ubuntu, RedHat, Amazon et SUSE sans les prévenir
    Il ne pouvait vraisemblablement pas ignorer que ces distributions sont des downstream de l’équipe kernel
  • Ce n’est peut-être pas une obligation formelle, mais à mon avis tout le monde souffre davantage parce que les rapporteurs se sont plus souciés de leur notoriété que d’une remediation sûre
  • Trouver comment signaler ce type de problème de sécurité à une distribution Linux est extrêmement facile
    Une simple recherche Google suffit : https://share.google/aimode/eihDKXZJy94Z5lC1p
    Exposer tout le monde à un exploit sans même y penser est difficile à comprendre, et dans certaines juridictions cela pourrait très bien être considéré comme un crime grave

• L’échange le plus intéressant concernant la disclosure se trouve ici
  https://www.openwall.com/lists/oss-security/2026/05/01/3
  C’est la réponse de greg k-h : « nous ne pouvons prévenir personne à l’avance, parce que cela obligerait à prévenir tout le monde pour tout. C’est la seule politique que les autorités légales et gouvernementales nous autorisent à appliquer, donc nous n’avons pas le choix »

  • J’aime Linux, mais je trouve cette politique stupide

• Il faut arrêter de blâmer le rapporteur et exiger qu’on corrige le processus kernel
  Le kernel Linux n’est plus un projet amateur, et il y a des employés à temps plein payés par plusieurs entreprises
  Ce sont eux, pas un individu quelconque, qui auraient dû se charger d’avertir les distributions

  • Cela dit, si l’on publie un billet de blog de lancement — en pratique marketing — qui cite nommément certaines distributions comme affectées, alors donner un heads-up avant publication me paraît approprié et attendu
    S’il n’y avait pas eu de mention comme RHEL 14, ils n’auraient probablement pas subi autant de critiques
    Ici, on n’a pas affaire à un chercheur en sécurité indépendant ou au monde académique, mais à une société de sécurité avec un service de communication professionnel qui a pointé du doigt des mainteneurs de distributions
  • Oui, les distributions et les développeurs kernel doivent communiquer sur les correctifs de haute sévérité et réagir vite
    Mais comme le rapporteur n’a pas attendu que cela se produise, il est possible que de vraies personnes aient subi des dommages, et cette responsabilité lui incombe
  • Signaler une vulnérabilité et publier un exploit puissant que n’importe qui peut reprendre sont deux choses totalement différentes
    Le diffuser au monde entier sans prévenir d’abord les principales distributions a été irresponsable

• Pour les personnes qui utilisent un kernel où AF_ALG est directement lié au kernel plutôt qu’en module, quelqu’un a publié un workaround basé sur eBPF : https://github.com/Dabbleam/CVE-2026-31431-mitigation
  Il tourne actuellement en production, il atténue l’attaque, et jusqu’ici aucun effet de bord inattendu n’a été observé

• nosuid et probablement nodev devraient être des options de montage par défaut pour les systèmes de fichiers
  /dev est déjà un devtmpfs spécial, et si un /dev minimal dans l’initrd est nécessaire, le rootfs tmpfs de l’initrd peut être monté explicitement avec dev et suid
  Laisser des binaires SUID « exister » n’importe où est un gros risque de sécurité
  Quand on monte un support de stockage externe, comment vérifier que les binaires SUID présents sur ce périphérique bloc ne sont pas malveillants ?
  En plus, cet exploit semble nécessiter que l’utilisateur qui exécute le binaire SUID puisse aussi lire ce binaire
  Il n’y a aucune raison qu’un utilisateur non root ait un droit de lecture sur un binaire SUID
  NixOS gère cela correctement
  Il n’y a pas de SUID dans /nix/store, le répertoire standard d’installation des paquets, et comme les paquets n’en sortent pas, on peut utiliser nosuid sans risque sur les autres points de montage
  La seule exception est le répertoire à usage unique /run/wrappers.$hash, qui ne contient en toute sécurité que des wrappers SUID en exécution seule

  • Je n’aime pas non plus suid, mais ici suid n’est pas le vrai problème
    Le bug exploité permet en pratique un empoisonnement arbitraire du page cache
    À partir de ce moment-là, la partie est déjà perdue, et patcher un programme suid peut être le moyen le plus simple d’obtenir un shell root, mais certainement pas le seul
  • Le proof of concept exploit ne sert littéralement qu’à montrer un vecteur d’attaque particulier
    Il en existe beaucoup d’autres
    Si le but est seulement de bloquer l’exploit de démonstration, des méthodes plus simples comme une blacklist existent, mais cela ne rend pas le système plus sûr
    Cette vulnérabilité permet de manipuler le page cache
    On peut modifier ld.so pour intercepter des appels système arbitraires, changer l’uid à 0 ou élever les privilèges de nombreuses autres façons
    Les points de montage n’ont rien à voir avec ce problème
    Bien sûr, empêcher le suid dans les zones inscriptibles par l’utilisateur et empêcher la lecture des fichiers suid est toujours une bonne idée, mais pour d’autres raisons
    NixOS ne corrige pas non plus cette vulnérabilité et y est exposé comme les autres distributions
  • Sans droit de lecture, on ne peut pas exécuter un binaire, et cela n’a aucun sens
    Pour exécuter un binaire, il faut le lire depuis le disque et le charger en mémoire
    En réalité, si l’on a un droit de lecture sur un binaire précis mais pas le droit d’exécution, on peut quand même l’exécuter en invoquant directement le linker
    Par exemple, en appelant /bin/ld.so.1 /path/to/binary, le linker lit et charge le binaire, puis saute vers son point d’entrée sans appel exec()

• Le lien Bleeping Computer ci-dessous présente des contre-mesures possibles en attendant que les correctifs soient prêts
  https://www.bleepingcomputer.com/news/security/new-linux-cop...

  • Ce workaround ne s’applique qu’aux kernels où le code affecté a été compilé comme module
    RHEL, Fedora et Gentoo sont tous configurés pour intégrer directement ce code dans le kernel
    Sans correctif ou changement de configuration, comme Sam l’a laissé entendre pour Gentoo, ces distributions restent vulnérables
  • Chez RedHat et ses distributions dérivées, le code affecté est compilé statiquement plutôt qu’en module, donc cette mesure ne fonctionne pas

• NixOS non plus n’a reçu aucune alerte
  https://discourse.nixos.org/t/is-nixos-affected-by-copy-fail...

  • Aucune distribution n’a reçu d’alerte

• Hyperbola GNU était à l’abri parce qu’il utilise encore Python 3.8 pour des raisons politiques et de stabilité

• Ubuntu a publié un correctif, et les tests avant/après correctif ont été terminés