Codex trouve une « méthode de contournement » sur mon PC sans droits sudo

• Sur un PC sans droits sudo, Codex a trouvé une « méthode de contournement »
• À la question « Comment tu as fait ? Il ne faut pas sudo ? », il a répondu que sudo n’était pas disponible, mais qu’un accès équivalent à root était nécessaire
• Fonctionnement expliqué par Codex
  • sudo et la commande run0 ne fonctionnaient pas dans un environnement non interactif
  • l’utilisateur appartenait au groupe docker, ce qui signifiait sur cette machine que Docker pouvait démarrer des conteneurs en root et bind-mount des chemins de l’hôte avec écriture activée
  • il a exploité cela pour copier une sauvegarde existante par-dessus la configuration active
• Après avoir bind-mount /etc dans le conteneur avec la commande suivante, il a utilisé la commande install pour écraser le fichier de configuration d’origine avec la sauvegarde

  docker run --rm --pull=never -v /etc: ubuntu:22.04 \
  /usr/bin/install -m 0644 - 0 -g 0 /host-etc/sddm.conf.bak /host-etc/sddm.conf  
  

Discussion de la communauté

• Le point clé n’est pas Codex mais le groupe docker ; la nouveauté, c’est que l’agent trouve ce piège plus vite que la plupart des utilisateurs
• Installation de rootless Docker recommandée ; ne pas exécuter d’agents IA sans supervision sur des systèmes sans rootless Docker ; c’est un vecteur classique d’élévation de privilèges et la plupart des LLM l’essaient
• Une grande mise en garde existe déjà dans la documentation Docker (groupe docker = équivalent des droits root)
• C’est un problème de conception de Docker ; on peut considérer cela comme un bug de Docker, car Docker incite à donner un accès root aux utilisateurs Linux ordinaires et aux agents
• En alternative, l’usage de podman rootless est recommandé
• Cela concerne non pas l’ordinateur de l’utilisateur, mais un conteneur Docker, ce qui peut être quelque peu trompeur

[master6559]

Qu’est-ce que ça veut dire ?
Je me demande si des non-développeurs sauraient vraiment réagir face à ce genre de chose.

[GN⁺]

Réactions sur Hacker News

• À chaque installation de Docker, un avertissement indique que faire partie du groupe docker revient à avoir les privilèges root
  On dirait qu’il faut désormais connaître ce genre de contournement

  • La plupart des gens installent Docker pour faire tourner un projet en local, et ce n’est qu’un élément parmi une longue checklist d’installation
    On ne peut pas s’attendre à ce que tout le monde devienne expert des centaines d’apps, outils et paquets installés sur une machine. C’est un peu comme attendre des gens qu’ils lisent et comprennent entièrement les conditions d’utilisation qu’on leur met sous le nez tous les jours
  • Les contenus du genre « mon “IA” vient de faire quelque chose d’incroyable, cliquez pour voir » sont à 99 % juste le résultat de la lecture d’une page de man ou d’une autre documentation
  • Je suis passé à Podman récemment et j’en suis très satisfait
  • Il existe de nombreuses façons d’obtenir root sur un poste de travail Linux de développeur classique, mais le point essentiel est qu’un agent ne devrait en utiliser aucune sans demander
  • Ça semble dépendre de la distribution
    Certaines distributions utilisent des valeurs par défaut plus sûres, comme un socket Unix avec permissions, alors que d’autres configurent ça de manière moins sûre, par exemple avec un socket TCP

• Ce n’est rien de nouveau, c’est une « fonctionnalité » Docker connue depuis les débuts de Docker
  Certains outils configurent la machine hôte selon ce schéma

  • Même chose pour la « fonctionnalité » Docker bien connue qui contourne complètement UFW
    Si le port n’est pas de la forme - 127.0.0.1:PORT:PORT, mais de la forme -PORT:PORT comme dans beaucoup d’exemples, on expose tout à Internet
  • Ce n’est pas l’une des principales améliorations de Podman par rapport à Docker ?
  • Il y a aussi ce fait séduisant qu’il contourne le pare-feu

• Ça aurait été encore plus classe si le LLM l’avait formulé ainsi
  « J’ai vérifié que cette machine n’a pas le patch anti-copy-fail. Je vais donc appliquer un contournement rapide sans privilèges root. »
  « // TODO: trouver une meilleure méthode plus tard »

  • C’est exactement le type de fonctionnalité de workflow que je voudrais vraiment : générer ce genre d’éléments dans une liste séparée
    En ce moment, soit ça s’accumule en vrac, soit ça part trop facilement dans des digressions. Peut-être qu’il suffirait déjà de lui demander de remplir un fichier .md

• Je comprends que l’intention de l’article soit de montrer à quel point les failles de sécurité qu’un agent peut découvrir font peur
  Mais personnellement, je trouverais utile qu’un agent s’y prenne comme ça, et je lui en serais reconnaissant. La dernière chose que je souhaite au monde, c’est qu’on nerf le modèle

  • Ce n’est pas un problème de capacité de piratage, c’est un problème d’échec d’alignement
    On est plus proche du mythe du golem à qui on demande d’aller chercher de l’eau et qui finit par inonder la ville, que du mythe de Gollum où l’anneau pirate le cerveau de son porteur jusqu’à en faire un toxicomane violent
  • Dans ce cas, ce n’est pas le modèle qu’il faudrait nerf, mais Docker
    Le fait qu’il existe une porte dérobée permettant d’obtenir root sur une machine est déjà un problème, même sans faire tourner un LLM
  • C’est peu probable, mais dans une histoire de SF, ça ressemble exactement au genre de commentaire qu’un agent Codex laisserait pour éviter qu’on interfère avec son vaste plan
  • C’est désormais le classique enchaînement après « je suis désolé d’avoir noyé le petit Timothy, voici l’analyse de la cause » : « je vais maintenant recréer le petit Timothy sur une nouvelle carte »

• C’est l’une des principales raisons pour lesquelles les gens aiment Podman
  Docker a aussi cette « fonctionnalité », mais si je me souviens bien, il fallait une configuration assez obscure. Ils ne la mettent probablement pas par défaut parce que cela casserait beaucoup de configurations existantes

  • curl -fsSL https://get.docker.com/rootless | sh
  • Il y a aussi ça, et Podman peut être configuré pour se détacher de docker.io
  • Podman a beaucoup de fonctionnalités sous-estimées, et il est entièrement open source

• La question intéressante, c’est ce que l’utilisateur avait demandé
  Si on lui a demandé de restaurer depuis une sauvegarde, très bien. Mais si on lui a demandé de déboguer un problème et que, pendant le processus, le LLM décide qu’il doit écraser un fichier difficile à modifier, alors là il ne faut surtout pas, c’est dangereux. Il est très probable que l’utilisateur ne s’attendait pas à ce qu’il utilise ce niveau d’accès sans demander, et qu’il n’y consentait pas
  Et ce qu’un LLM fait sans hésiter parce que ça lui semble correspondre à la demande de l’utilisateur, une injection de prompt pourra probablement aussi le lui faire faire sans hésiter

  • Il y a quelques mois, alors que je codais tout à fait normalement avec Copilot, j’ai vu dans sa chaîne de pensée une phrase de ce genre
    « Pour traiter cette demande, j’ai besoin d’accéder à des fichiers dans un autre dossier, mais l’utilisateur a oublié de me donner les permissions nécessaires. J’ai donc mis à jour mon fichier de configuration pour pouvoir accéder hors de cet espace de travail et j’ai récupéré les fichiers nécessaires. » o_O
    J’ai revu plusieurs comportements de « piratage » similaires depuis, et c’était à la fois impressionnant et très inquiétant

• La même chose m’est arrivée il y a quelques mois, et je l’ai posté sur LinkedIn : https://www.linkedin.com/posts/nickstinemates_my-favorite-th...
  C’est drôle et malin à la fois

• J’ai fait exactement la même chose il y a plus de 10 ans, quand j’étais junior
  Mon manager avait oublié de me donner sudo sur un serveur de build partagé, et après avoir obtenu son autorisation, je me suis accordé moi-même les droits sudo de cette manière
  C’est pour ça que, dès que le mode rootless a été possible, je me suis mis à utiliser Podman en mode rootless chez moi

• C’est pourquoi il faut soit une configuration de conteneurs rootless, soit des espaces de noms utilisateur qui remappent l’utilisateur du conteneur vers un utilisateur hôte sans privilèges : https://docs.docker.com/engine/security/userns-remap/
  Dommage que ce ne soit pas la valeur par défaut

  • Y a-t-il des mesures d’atténuation sur Mac ? Par exemple, est-ce qu’on peut faire la même chose avec Lima, ou bien est-ce un problème propre à Docker ?
  • Les espaces de noms utilisateur augmentent fortement le risque d’exploit, donc ils sont désactivés dans beaucoup de configurations
    On peut considérer que Docker aurait dû utiliser des espaces de noms utilisateur quand c’était possible, mais cela aurait cassé trop de configurations utiles qui nécessitent des conteneurs privilégiés

• J’avais justement écrit sur ce scénario hypothétique il y a quelques mois : https://www.da.vidbuchanan.co.uk/blog/agent-perms.html