Une nouvelle faille du noyau Linux, baptisée « ssh-keysign-pwn », permet d'obtenir un accès root sur les principales distributions

En bref

Quoi : Une faille permettant l'escalade des privilèges locaux sous Linux dans __ptrace_may_access(), communément appelé ssh-keysign-pwn (ou chage_pwn d'après le PoC phare). Aucun numéro CVE n'avait encore été attribué au moment de la publication.

Conséquences : A démonstration de faisabilité publique permet de faire passer de manière fiable un utilisateur local sans privilèges au niveau root en exploitant des binaires SUID via cette faille : chage fuir /etc/shadow, ssh-keysign de divulguer les clés privées des hôtes SSH.

Statut : Le correction en amont (valider 31e62c2) est sorti au même moment que le communication publique sur oss-security. Aucun numéro CVE n'a encore été attribué, l'avis de Qualys n'a pas encore été publié et aucun score CVSS n'est disponible pour l'instant. KernelCare a publié des correctifs sans redémarrage pour Ubuntu 22.04 (Jammy), Debian 11 (sur ePortal) et la famille EL9 (dans les dépôts test et main), RHEL 8/Rocky Linux 8 (dans le flux de test).

Gravité : vecteur local, aucun privilège requis, aucune intervention de l'utilisateur, aucune configuration particulière. Le PoC public fonctionne dès l'installation sur Debian 11/12/13, Ubuntu 22.04/24.04/26.04, Arch, Raspberry Pi OS Bookworm, ainsi que sur les familles EL9 et EL10. EL8 et Ubuntu 20.04 sont vulnérables mais nécessitent un PoC adapté. EL7 sur le noyau 3.10 n'est pas affecté.

Pourquoi est-ce important ? Étant donné que cette faille cible des binaires SUID courants et ne nécessite ni privilèges ni intervention de l'utilisateur, les systèmes Linux multi-utilisateurs vulnérables doivent être considérés comme exposés à un risque immédiat.

Faites-le tout de suite : Resserrer Yama ptrace_scope sur les serveurs (une option sysctl, réversible). KernelCare Les clients sont invités à surveiller la publication du flux de test. Vous trouverez ci-dessous les commandes d'atténuation ainsi que les instructions pour le déploiement des correctifs sans redémarrage.

La version longue

Une faille de sécurité critique du noyau Linux a été signalée ce matin sur GitHub, sans numéro CVE, sans avis de la part du chercheur à l'origine de la découverte, et accompagnée d'un code de preuve de concept (PoC) public fonctionnant sur une machine Debian ou Ubuntu standard. La faille se trouve dans __ptrace_may_access(). Le correctif a été intégré en amont dans le même délai – une bonne nouvelle, sauf que personne en dehors des équipes chargées du noyau de la distribution n'y aura accès avant plusieurs jours.

Voici les détails précis de la chronologie. Jann Horn a proposé une correction équivalente pour ce bug en 2020. Elle n’a pas été intégrée. La cause profonde est restée présente dans toutes les branches stables du noyau pendant cinq ans, jusqu’à ce qu’un chercheur de Qualys la redécouvre et qu’un deuxième chercheur publie deux exploits fonctionnels dans le dépôt ssh-keysign-pwn quelques heures seulement après la divulgation en amont.

Le correctif KernelCare sans redémarrage est en cours de compilation. En attendant sa mise à disposition, il existe une option sysctl qui bloque immédiatement la démonstration de concept publique. Voici ce qui se passe et ce qu'il faut faire dès maintenant.

Comment fonctionne cette faille

Une refonte de 2017 de __ptrace_may_access() (valider bfedb589, v4.10-rc1) a inversé en silence la vérification des droits d'accès lorsqu'une tâche mm est NULL. Avant la refonte, le code refusait l'accès dans cet état. Le code refondu passe directement à l'autorisation.

Lors de la sortie du processus, il existe une fenêtre de l'ordre de la microseconde pendant laquelle task->mm est déjà effacé, mais les descripteurs de fichiers de la tâche sont toujours actifs. Le PoC public lance un processus SUID dans cette fenêtre en utilisant pidfd_open et pidfd_getfd, avec deux cibles prêtes à l'emploi dans le référentiel : chage fuir /etc/shadow, et ssh-keysign pour divulguer les clés privées des hôtes SSH. Le taux de réussite signalé est de 100 à 2 000 instances générées par opération réussie.

Jann Horn a proposé une solution équivalente en 2020 (v1, v2). Elle n'a pas été intégrée, et le bug est resté latent.

Qui est concerné ?

Cette régression a été rétroportée dans la série stable v4.4.40; par conséquent, pratiquement tous les noyaux de distributions modernes non EL7 sont concernés par défaut. Trois groupes :

Le PoC public fonctionne dès son installation :

• Debian 11, 12, 13
• Ubuntu 22.04, 24.04, 26.04
• Arch Linux (version actuelle)
• Raspberry Pi OS Bookworm
• CentOS Stream 9, AlmaLinux 9, RHEL 9, Oracle Linux 9, Rocky Linux 9
• AlmaLinux 10, RHEL 10

Vulnérable, mais le PoC doit être adapté :

• Famille EL8 (RHEL 8, AlmaLinux 8, Rocky 8, Oracle Linux 8)
• Ubuntu 20.04

Non concerné :

• La famille EL7 sur le noyau 3.10 – antérieure à la régression de 2017

Agir dès maintenant

Resserrer Yama ptrace_scope. L'exploit exploite la faille via pidfd_getfd(). pidfd_getfd() appels ptrace_may_access(…, PTRACE_MODE_ATTACH_REALCREDS), qui exécute le hook LSM à la fin de __ptrace_may_access. Un déni de Yama contourne le bug, même si le traitement par défaut de mm-NULL est défectueux.

Le commun ptrace_scope=1 La configuration par défaut (telle qu'elle est fournie avec Debian/Ubuntu) n'est PAS suffisante. Sous scope=1, la liaison parent-processus-fils est autorisée. L'attaquant lance lui-même le processus SUID, ce qui lui permet de sont le parent. Vous devez déménager à scope=2 ou scope=3.

Recommandé : ptrace_scope=2 (ajout réservé à l'administrateur, entièrement réversible pendant l'exécution) :

sudo sysctl -w kernel.yama.ptrace_scope=2

Rétablir la configuration d'origine une fois le correctif sans redémarrage installé :

sudo rm /etc/sysctl.d/99-ssh-keysign-pwn.conf

Plus fort : ptrace_scope=3 (pas de fichier joint pour personne, irréversible sans redémarrage) :

sudo sysctl -w kernel.yama.ptrace_scope=3

scope=3 c'est un aller simple jusqu'au redémarrage : le noyau rejette toute tentative ultérieure de le réduire (sysctl -w kernel.yama.ptrace_scope=2 retours EINVAL). Ne sélectionnez cette option que si vous acceptez de redémarrer pour annuler l'opération et si le débogage en mode root (gdb -p, strace -p (en tant qu'administrateur) ne fait pas partie de vos opérations habituelles.

Compatibilité

• scope=2 interrompt les processus non privilégiés gdb -p / strace -p / perf trace --pid et les flux de débogage des conteneurs root conserve l'attachement, ce qui signifie que le dépannage administratif fonctionne toujours.
• scope=3 Cela empêche tout le monde, y compris l'utilisateur root, d'utiliser la commande `debug-attach`.

Correctif sans redémarrage KernelCare

KernelCare a publié des correctifs sans redémarrage pour Ubuntu 22.04 (Jammy), Debian 11 (sur ePortal), la famille EL9 (dans les dépôts « test » et « main »), ainsi que RHEL 8/Rocky Linux 8 (dans le dépôt « test »).

Une fois publié dans le flux de test :

kcarectl --update --prefix test

Une fois validé, le correctif est déployé lors de la prochaine exécution planifiée, ou vous pouvez le récupérer à la demande :

kcarectl --update

À surveiller au fur et à mesure que la situation évolue

• Référence CVE : (aucune au moment de la rédaction)
• L'avis publié par Qualys, qui devrait comporter une description technique plus détaillée
• Mises à jour du noyau provenant de Debian, d'Ubuntu et des fournisseurs d'EL9/10
• De nouvelles modifications ont été apportées au dépôt public ssh-keysign-pwn – il est peu probable que les deux cibles actuelles soient les seules viables

Nous mettrons à jour cet article dès que le CVE sera publié et que le correctif KernelCare passera de la version de test à la version stable. Si vous utilisez KernelCare, le correctif sera déployé automatiquement ; vous n'avez donc aucune intervention à effectuer.

Si vous n'utilisez pas encore KernelCare, c'est le moment idéal pour découvrir comment les correctifs sans redémarrage peuvent protéger vos systèmes Linux critiques sans nécessiter de fenêtres de maintenance d'urgence ni de temps d'arrêt.

Pour en savoir plus sur KernelCare, cliquez ici →