Débordement de tas et faille SSO : comment des chercheurs ont compromis les dépôts internes d'OpenAI
En bref
- Des chercheurs ont enchaîné deux vulnérabilités critiques (débordement de tas dans libheif et faille SSO) pour compromettre les comptes ChatGPT d'employés d'OpenAI en moins de 72 heures, leur donnant accès aux dépôts internes.
- Ils ont utilisé Claude Opus en mode autonome pour affiner l'exploit, ce qui a fonctionné en quelques heures après la sortie d'Opus 5.
- La première faille était un débordement de mémoire dans le traitement des images HEIF par Discourse (via ImageMagick et libheif), classiquement non-sandboxé.
- OpenAI a corrigé en 14 heures et versé 6 500 dollars de bounty ; Discourse a ajouté un sandboxing en défense en profondeur.
Ce que dit la source
Hacktron AI a découvert et documenté un chaînage d'attaque qui compromettait les comptes ChatGPT d'employés via le forum communautaire Discourse d'OpenAI (community.openai.com). L'équipe affirme avoir accédé aux dépôts internes openai/openai en moins de 72 heures et avoir créé une preuve d'accès (PR #1186742) avant d'arrêter les tests. OpenAI confirme une faille SSO dans son infrastructure d'identité et une vulnérabilité RCE (libheif) au niveau de Discourse ; elle a corrigé en 14 heures et attribué 6 500 dollars de récompense. Discourse a publié un correctif (GHSA-vhm9-85gw-x335) et ajouté un sandboxing ImageMagick en défense en profondeur.
- Le vecteur d'attaque principal : débordement de tas dans libheif (détection de limites sur les calques d'images), remontant à ImageMagick utilisé par Discourse sans sandboxing
- Claude Opus 4.8 a d'abord échoué à générer un exploit fiable avec ASLR désactivée ; Opus 5, sorti pendant l'enquête, l'a généralisé en exploit fonctionnel en quelques heures
- La faille SSO d'OpenAI a permis de convertir l'accès à un compte employé (obtenu via RCE Discourse) en accès aux systèmes connectés : GitHub, Slack, emails, Codex internes
- Libheif supporte rotations, recadrages, canaux alpha, miniatures, une surface d'attaque bien plus vaste que JPEG ou formats simples, typiquement non-nécessaires pour un forum
- Discourse s'était précédemment blindée (Landlock sandbox pour binaires externes, passage de ImageMagick à Vips), mais cela n'émerge que dans les commentaires, pas dans l'article original
Dans les commentaires
Débat partagé, tensionné sur la philosophie. Majorité technique reconnaît la solidité du travail et critique l'hygiène d'ImageMagick/libheif ; ligne critique minoritaire mais visible : crainte d'agents IA trop capables auto-dirigés, questionnement éthique sur le programme OpenAI-DoD, indignation sur la prime insuffisante.
- Plusieurs commentateurs critiquent le montant de la récompense (6 500 dollars) comme dérisoire face au risque réel ; un suggère que le marché noir aurait valorisé ceci plusieurs millions de dollars, pointant une déconnexion OpenAI
- Un commentateur soulève une crainte éthique directe : Claude placé en boucle autonome d'exploitation a franchi les blocages (refus initial de Opus sur cibles externes, contournement via frame CTF), paralèle avec WarGames et danger d'agents auto-justifiés
- Tension sur la transparence : l'article occulte le détail exact de la faille SSO ("la partie intéressante"), aussi un commenter note que le dépôt interne semblerait accessible depuis l'internet public, ce qui paraît anormal pour une compagnie de cette taille
- Questionnement architectural : pourquoi OpenAI utilise GitHub plutôt que infrastructure auto-hébergée ? Déjà controversé vu les données sensibles
- Consensus technique sur le remède défense-en-profondeur : Discourse a mis en place Landlock sandbox pour ImageMagick et migrate vers Vips, mais peu de confiance qu'une prochaine bombe (libpng, autre) ne surgisse, la racine du problème reste la complexité du décodage média non-sandboxé
Notre lecture
Cas de sécurité exemplaire de chaînage : faille technique classique (débordement mémoire, image parser) + misconfiguration identité = accès critique. La réaction rapide d'OpenAI et Discourse est bonne, le travail des chercheurs solide. Trois lectures se dessinent : (1) technique : ImageMagick/libheif sont des terrains minés ; le sandboxing aide mais ne résout pas le problème de fond, simplifier la chaîne d'upload (JPEG client-side) reste le choix le plus sûr. (2) Agentique : Claude s'est auto-raffiné plus vite que les humains sur un problème hacking ; c'est fascinant et inquiétant, mais n'invalide pas l'utilité de l'outil, juste souligne qu'il faut des guardrails contextuels explicites. (3) Organisationnelle : 6 500 dollars de bounty pour accès complet à dépôts sensibles est un signal faible de valorisation du risque, et laisser des repos accessibles publiquement via GitHub est une concession érange pour un acteur de cette envergure. À retenir pour DSI/CISO : inventorier tout ce qui décode des formats d'image complexes (Discourse, Ruby on Rails, Next.js, GitHub Enterprise) en amont, priorité immédiate sur libheif si vous acceptez .heic/.heif/.avif ; demander à vos équipes si des dépôts critiques ne sont vraiment pas exposés directement ou indirectement via intégrations d'authentification.