CVE-2026-11837 : escalade de privilèges locale avec authorized_key de ansible.posix

Escalade de privilèges locale dans le module Ansible ansible.posix.authorized_key via chown suivant les liens symboliques (et création de fichier suivant les liens symboliques) sur le répertoire ~/.ssh d'un utilisateur et le fichier authorized_keys.

Ceci est une description d'une vulnérabilité que j'ai signalée et à laquelle a été attribué CVE-2026-11837 par Red Hat Product Security (le CNA). Elle est publiée ici à titre de documentation technique, et non comme une revendication de nouveauté : le problème est le jumeau de CVE-2024-9902 dans un module que le correctif précédent n'a pas couvert.

Références officielles

• Enregistrement CVE Red Hat : https://access.redhat.com/security/cve/CVE-2026-11837
• Défaut Bugzilla Red Hat : https://bugzilla.redhat.com/show_bug.cgi?id=2487424
• Code source du module concerné : https://github.com/ansible-collections/ansible.posix/blob/main/plugins/modules/authorized_key.py

Accusé de réception publié par Red Hat : "Red Hat remercie Valentino Paulon pour avoir signalé ce problème."

Résumé

Lorsqu'un playbook s'exécutant en tant que root utilise ansible.posix.authorized_key pour gérer les clés d'un utilisateur local, l'assistant keyfile() du module :

• change la propriété du répertoire ~/.ssh de l'utilisateur et du fichier ~/.ssh/authorized_keys avec un simple os.chown (pas os.lchown), et
• crée le fichier de clés avec un simple open(..., "w") (pas de O_NOFOLLOW).

Avec la valeur par défaut follow=False, le module ne suit ni ne remplace les liens symboliques et ne les refuse pas non plus ; il opère directement sur le chemin, donc le noyau suit tout lien symbolique que l'utilisateur cible non privilégié a pré-positionné dans son propre ~/.ssh. Cela donne deux primitives qui transfèrent la propriété d'un chemin contrôlé par root à l'utilisateur non privilégié, qui élève ensuite ses privilèges à root. Les deux ont été reproduites de bout en bout sur la collection à HEAD.

Code concerné et cause racine

keyfile() (plugins/modules/authorized_key.py), avec les valeurs par défaut manage_dir=True, follow=False :

if manage_dir:
    if not os.path.exists(sshdir):          # os.path.exists SUIT les liens symboliques
        try:
            os.mkdir(sshdir, int('0700', 8))
        ...
    os.chown(sshdir, uid, gid)              # INCONDITIONNEL, chown simple, suit le lien symbolique
    os.chmod(sshdir, int('0700', 8))        # suit le lien symbolique

if not os.path.exists(keysfile):           # suit le lien symbolique
    ...
    f = open(keysfile, "w")                # open() simple, pas de O_NOFOLLOW, suit le lien symbolique
    ...
try:
    os.chown(keysfile, uid, gid)           # INCONDITIONNEL, chown simple, suit le lien symbolique
    os.chmod(keysfile, int('0600', 8))     # suit le lien symbolique
except OSError:
    pass

sshdir et keysfile sont dérivés du répertoire personnel de l'utilisateur cible dans passwd (pwd.getpwnam(user).pw_dir), un répertoire que l'utilisateur cible non privilégié possède et contrôle. Le paramètre follow (par défaut False) choisit uniquement d'appeler os.path.realpath() sur le chemin ; dans aucun cas il n'y a de vérification os.path.islink, d'ouverture avec O_NOFOLLOW, d'utilisation de os.lchown, ou de suppression et remplacement d'un lien symbolique préexistant. Aucune baisse de privilège (seteuid/setfsuid) n'est effectuée ; tout s'exécute en tant que root.

Les deux appels os.chown s'exécutent inconditionnellement, en dehors des gardes if not os.path.exists(...), donc ils se déclenchent que le répertoire/fichier existe déjà ou non. C'est ce qui rend les deux primitives fiables.

Deux primitives

Les deux ont été confirmées de bout en bout sur une machine Linux jetable, avec ansible.posix à HEAD. victim est un utilisateur local non privilégié (uid 1000). Le module est exécuté en tant que root, exactement comme le ferait le playbook d'un opérateur. Des leurres représentent des cibles root sensibles.

Vecteur 1 : lien symbolique de répertoire (chown d'un répertoire existant appartenant à root)

1. En tant que victim : ln -s /root/AD_CANARY ~/.ssh (avec /root/AD_CANARY un répertoire existant appartenant à root).
2. L'opérateur exécute la tâche authorized_key pour victim.
3. Observé : le propriétaire de /root/AD_CANARY est passé de root:root à victim:victim. L'appel os.chown(sshdir, ...) a suivi le lien symbolique ~/.ssh et a remis un répertoire appartenant à root à l'utilisateur non privilégié.

Vecteur 2 : lien symbolique de fichier cassé (création + chown d'un nouveau fichier dans un chemin root)

1. En tant que victim (avec ~/.ssh un répertoire normal) : ln -s /root/AF_CANARY ~/.ssh/authorized_keys (la cible n'existe pas).
2. L'opérateur exécute la tâche authorized_key pour victim.
3. Observé : /root/AF_CANARY a été créé, appartenant à victim:victim, mode 0600. open(keysfile, "w") a créé la cible via le lien symbolique et os.chown(keysfile, ...) l'a remise à l'utilisateur non privilégié.

Dans les deux cas, l'utilisateur non privilégié finit par posséder un chemin contrôlé par root. Pointer le lien vers un répertoire sous /etc (Vecteur 1) ou vers un nouveau fichier sous /etc/cron.d/ ou /etc/sudoers.d/ (Vecteur 2) permet d'obtenir root par la suite standard, où l'utilisateur, désormais propriétaire, réécrit la cible.

Relation avec CVE-2024-9902

Ceci est un jumeau de CVE-2024-9902 (le generate_ssh_key du module user, dans ansible-core), qui traitait la même classe de suivi de liens symboliques. authorized_key réside dans la collection distincte ansible.posix et n'a pas été modifié par ce correctif ; le motif chown/création suivant les liens symboliques était toujours présent et non protégé. Il est signalé comme la même classe acceptée dans un module que le correctif précédent n'a pas atteint, et non comme une cause racine nouvelle.

Impact et préconditions honnêtes

• Élévation de privilège d'un utilisateur local non privilégié à root sur un hôte géré par Ansible.
• Conditionné à ce qu'un opérateur exécute une tâche ansible.posix.authorized_key ciblant le compte de la victime (l'utilisation courante de ce module). L'utilisateur local pré-positionne le lien symbolique dans son propre ~/.ssh ; il n'exécute pas le playbook. C'est déclenché par l'opérateur : le même modèle de déclenchement que CVE-2024-9902, que Red Hat a accepté avec l'atténuation « ne pas exécuter contre des comptes non fiables ». La précondition est énoncée explicitement plutôt que considérée comme auto-déclenchée.

Correctif suggéré

• Créer le fichier de clés sans suivre les liens symboliques et de manière exclusive : os.open(keysfile, os.O_WRONLY | os.O_CREAT | os.O_EXCL | os.O_NOFOLLOW, 0o600) et opérer sur le descripteur ; refuser (ou supprimer et remplacer, selon le contrat de la docstring de follow=False) si sshdir ou keysfile est un lien symbolique.
• Remplacer os.chown(...) par os.lchown, ou par os.fchown sur un descripteur ouvert en toute sécurité, et de même os.fchmod au lieu de os.chmod, afin que la propriété et les permissions ne puissent pas être redirigées via un lien.
• Conditionner les chown/chmod inconditionnels pour qu'ils ne s'appliquent qu'à un chemin que le module lui-même vient de créer en toute sécurité, et non à un chemin préexistant (éventuellement lié par un lien symbolique).

Calendrier de divulgation

Licence

MIT. Voir LICENSE.