ssh-keysign-pwn - PoC d’un 0-day Linux permettant à un utilisateur non privilégié de lire des fichiers appartenant à root

• ssh-keysign-pwn est une PoC d’une vulnérabilité Linux permettant à un utilisateur non privilégié de lire des fichiers appartenant à root, et indique que les noyaux antérieurs à 31e62c2ebbfd sont concernés
• Le bug principal vient du fait que __ptrace_may_access() ignore la vérification dumpable lorsque task->mm == NULL, et que do_exit() exécute exit_mm() avant exit_files(), créant une fenêtre où les descripteurs de fichiers restent ouverts
• Dans cette fenêtre, si l’uid de l’appelant correspond à celui du processus cible, pidfd_getfd(2) réussit, ce qui permet de récupérer les descripteurs de fichiers ouverts d’un processus en cours de terminaison
• sshkeysign_pwn récupère /etc/ssh/ssh_host_{ecdsa,ed25519,rsa}_key en exploitant le flux où ssh-keysign.c ouvre des clés avec des permissions 0600 puis quitte avec EnableSSHKeysign=no avant permanently_set_uid(), en laissant un fd ouvert
• chage_pwn récupère /etc/shadow et vise une race de sortie dans le flux où chage -l <user> appelle spw_open(O_RDONLY) puis abandonne complètement ses privilèges avec setreuid(ruid, ruid)
• L’exécution consiste à lancer make, puis ./sshkeysign_pwn pour les clés hôte, et ./chage_pwn root pour afficher le contenu de /etc/shadow sur la sortie standard ; le README indique qu’un succès survient en 100 à 2000 créations de processus
• Les environnements confirmés sont Raspberry Pi OS Bookworm 6.12.75, Debian 13, Ubuntu 22.04 / 24.04 / 26.04, Arch et CentOS 9
• Comme PoC contrôlée pour la cible, vuln_target.c ouvre /etc/shadow puis abandonne ses privilèges, et exploit_vuln_target.c montre EPERM tant que le processus est vivant puis le vol de fd après SIGKILL
• La vulnérabilité a été signalée par Qualys et corrigée par Linus le 2026-05-14 ; Jann Horn avait indiqué dès octobre 2020 une forme de vol de FD
• Le README renvoie vers l’entrée NVD https://nvd.nist.gov/vuln/detail/CVE-2026-46333

[GN⁺]

Avis sur Lobste.rs

• Désactiver ptrace ne suffit pas. Le message de commit et le nom de la fonction induisent facilement en erreur, mais ptrace_may_access est appelé par plusieurs chemins et cette preuve de concept (PoC) n’utilise en fait pas ptrace
  Il n’y a pas vraiment de bonne mesure d’atténuation et, pour l’instant, cela semble se limiter à 1) retirer complètement le bit d’exécution de /usr/lib64/misc/ssh-keysign pour ne contrer que faiblement cette PoC précise, ou 2) bloquer pidfd_getfd avec quelque chose comme eBPF ou systemtap. La première option n’est à envisager que si vous ne pouvez ni patcher le noyau ni éteindre la machine et que vous devez aller dormir immédiatement
  Je n’ai pas examiné la PoC et, comme toujours, il faut faire très attention avant d’exécuter une PoC arbitraire récupérée sur Internet
  L’avis de Qualys n’a pas encore été publié, et l’équipe a déclaré, avec beaucoup de regret, qu’elle cesserait d’utiliser la liste linux-distros à cause de la politique de sécurité du noyau Linux. La situation est devenue plus rude maintenant que des LLM peuvent produire rapidement une PoC à partir d’un commit de correction suspect, alors qu’autrefois on aurait peut-être pu attendre quelques jours
  Qualys est vraiment une excellente équipe, et c’est dommage qu’elle n’ait pas eu l’occasion d’annoncer elle-même correctement cette affaire. Quand l’avis sortira, il sera sans doute excellent
  OpenSSH n’est qu’une cible pratique pour cette attaque et n’est pas en faute ; on pourrait probablement choisir d’autres binaires setuid comme cibles

  • Selon la mise à jour de Qualys, régler /proc/sys/kernel/yama/ptrace_scope sur 2 (attache admin uniquement) ou 3 (aucune attache) bloque tous les exploits connus. Théoriquement, d’autres formes d’exploitation restent toutefois possibles
  • Comme atténuation rapide, j’ai demandé à Opus, un LLM, d’écrire un script systemtap qui bloque pidfd_getfd, et le résultat est ici. Il faut le lancer avec stap -g block_pidfd_getfd.stp, et comme pour tout ce qui vient d’Internet, il faut absolument relire le script avant exécution
  • Y a-t-il un lien vers l’annonce sur linux-distros ? Je n’arrive pas à le trouver

• J’aimerais que le noyau arrête de faire lui-même des divulgations 0-day en publiant des commits de correction sur la branche principale. Le commit mentionne même « Reported-by: Qualys », donc il est évident qu’il s’agit d’un correctif de sécurité

  • Il y a eu un gros débat à ce sujet la semaine dernière
    Greg K-H a écrit que l’équipe sécurité du noyau ne pouvant pas choisir à qui divulguer à l’avance les correctifs de sécurité, au final personne n’en reçoit à l’avance
  • Et qu’est-ce qu’il faudrait faire à la place ?

• Ce n’est pas un problème SSH, c’est un problème Linux. Le titre devrait le refléter

  • Je suis d’accord sur le fait que le titre prête à confusion, mais je n’avais pas d’autre idée de formulation. Je peux encore le modifier, donc je veux bien des suggestions
  • Oui, mais en même temps, si ssh-keysign avait vérifié EnableSSHKeysign=yes avant d’ouvrir la clé d’hôte privée, alors les systèmes où cette option est désactivée par défaut n’auraient pas été vulnérables au vol de clé d’hôte. Il est surprenant que ssh-keysign ne vérifie pas cette option en tout premier

• La preuve de concept est agréablement courte, et mes machines étaient effectivement vulnérables
  Il semble qu’elle permette, dans certaines conditions, d’accéder à des descripteurs de fichier ouverts par un exécutable setuid. Je ne vois pas pourquoi cela se limiterait à la lecture, et ça pourrait probablement être transformé en élévation locale de privilèges (LPE) sans avoir à casser de hash
  On peut neutraliser cette PoC précise avec chmod -x /usr/lib/openssh/ssh-keysign /usr/bin/chage. Il faudra peut-être adapter le chemin de ssh-keysign, et la page de manuel peut aider. Mais cela ne corrige pas le problème de fond et il semble probable qu’on puisse le contourner. À ma connaissance, il n’existe pas d’autre atténuation
  Le problème a été corrigé dans ptrace: slightly saner 'get_dumpable()' logic, et c’est ainsi qu’il a été divulgué. C’était il y a à peine 10 heures
  Il y a aussi l’annonce publique de Qualys sur oss-security, qui dit qu’ils ne publient pas encore l’avis afin de laisser le temps aux distributions et aux utilisateurs d’appliquer des correctifs. Cela s’annonce assez intéressant et, en attendant, on peut lire l’explication de Brad Spengler de grsecurity. Ce tweet semble avoir déclenché le développement de cette PoC

  • J’ai essayé d’exécuter la PoC, mais je n’ai pas gagné la course critique. En revanche, la paire exploit_vuln_target/vuln_target a bien fonctionné. Ce n’est pas très rassurant

• En pratique, cela semble toucher des systèmes où un utilisateur dispose déjà d’un compte non privilégié. Autrement dit, sans identifiants valides, on est bien d’accord que cela ne permet pas d’obtenir directement une exécution de code à distance sur un serveur SSH exposé à Internet ?

  • Oui. Sauf, bien sûr, si l’on peut obtenir une RCE via un autre service, comme avec la RCE nginx mentionnée il y a quelques jours