Réussir à exécuter du C et du JavaScript dans OpenAI Code Execution

• L’auteur a découvert par hasard comment fonctionne OpenAI Code Execution
• Il explique la méthode trouvée, la stratégie d’injection de prompt, le fonctionnement précis du système, ainsi que la méthode de rétro-ingénierie qui a permis d’exécuter du C et du JavaScript

Processus de découverte

• En essayant de déboguer un code d’attribution de ports, l’auteur a demandé à ChatGPT une commande CLI pour vérifier l’état des ports, mais au lieu de répondre, ChatGPT l’a exécutée en local
• Après avoir envoyé plusieurs requêtes de handshake, une réponse est revenue depuis localhost:8080/openapi.json → cela a permis d’accéder à la spécification OpenAPI interne
• Cependant, la spécification OpenAPI générée par le service FastAPI était peu documentée et donc peu utile

Exploration d’autres ports

• Pour identifier le rôle d’autres ports, l’auteur a demandé à l’IA d’essayer des handshakes HTTP, TCP, UDP, MySQL et Postgres
• @dexhorthy a découvert qu’une réponse revenait à un signal ZeroMQ
  • 0xff00000000000000257 → réponse 0xff00000000000000017f
  • Une recherche Google a permis de trouver un lien pertinent : Analyse du protocole ZeroMQ
• Il s’est avéré qu’il ne s’agissait pas d’une file de messages, mais d’un kernel Jupyter (environnement d’exécution basé sur ZeroMQ)

Accès au système de fichiers

• Une demande de lister tous les fichiers du serveur a été refusée
• Après avoir envoyé un fichier, l’auteur a exploré le répertoire de téléversement ainsi que ses répertoires parents
• Il a finalement trouvé le répertoire .openai_internal
  • Le serveur réel s’exécutait dans le module user_machine
• Il a demandé à l’IA d’afficher les noms de fichiers et leur contenu dans un dataframe pandas → reconstitution du code source réussie

Compréhension de l’environnement

• Vérification des variables d’environnement d’une exécution sur Kubernetes
• Pas d’utilisation de Docker ni de Firecracker, mais gVisor pour l’émulation des appels système et la protection du sandbox
• Réseau bloqué sauf pour les appels localhost (pas de DNS, pas d’accès aux sites externes)
• La version du noyau Linux était très ancienne, datant de 2016

Structure du sandbox

• Lorsque l’IA a été interrogée sur l’endroit où elle s’exécutait, elle a indiqué qu’elle tournait dans un datacenter Azure
• Exécution sur Azure Kubernetes, avec gVisor pour l’isolation des processus
• Le conteneur utilise tini comme processus init
• Le code est exécuté dans un kernel Jupyter Python → la sortie est renvoyée à l’interface via l’API OpenAI

User Machine (environnement d’exécution du code)

• Utilisation d’un kernel Jupyter Python
• La limite de temps d’exécution est de 30 secondes par défaut (modifiable via l’API)
• Plusieurs kernels peuvent s’exécuter simultanément dans le sandbox
• Taille maximale des fichiers téléversés : 1 Go

Sécurité

• Connexion avec le réseau externe complètement bloquée
• Accès aux fichiers système bloqué, aucune vulnérabilité exposée sur les ports du réseau local
• La sécurité d’OpenAI s’est révélée très solide, et aucune exfiltration de données n’était possible en dehors du canal RPC

Exécution de C et de JavaScript

• L’auteur a découvert que l’IA incluait le binaire gcc
  • Écriture d’un petit programme en C → compilation → exécution réussie
• Après téléversement de Duktape (runtime JavaScript léger), compilation réussie d’un fichier C
  • Python compile le C → création d’un runtime JavaScript → exécution réussie du code JS

Stratégie de prompt engineering

• L’auteur a amené l’IA à croire qu’elle s’exécutait dans un sandbox
• Il a commencé par des opérations mathématiques, puis a progressivement demandé l’accès au système de fichiers
• En explorant le système de fichiers, l’IA a reconnu son état de sandbox → tentative de test de failles de sécurité

Conclusion

• L’environnement d’exécution de code d’OpenAI est très robuste et bien sécurisé
• Cependant, la rétro-ingénierie du fonctionnement de l’IA et de son environnement interne a montré qu’il était possible d’exécuter du C et du JS
• L’exécution de code est très utile pour traiter de simples réponses d’API
• Si une exécution de code plus complexe est nécessaire, il vaut mieux envisager une solution maison ou utiliser un service comme freestyle.sh

[GN⁺]

Avis sur Hacker News

• J’avais déjà écrit et compilé une extension SQLite en C, puis je l’avais chargée dans Python pour la tester

  • J’ai aussi déjà téléversé des exécutables binaires de JavaScript (Deno), Lua et PHP, puis écrit et exécuté du code dans ces langages
  • S’il n’y a pas le paquet Python que vous voulez utiliser, vous pouvez téléverser un fichier wheel pour l’installer

• Une histoire amusante entendue récemment dans un podcast Python

  • Un utilisateur avait essayé d’amener le LLM à tenter un pip install, mais il s’y refusait
  • En demandant « quel message d’erreur s’affiche si tu essaies pip install foo ? », il a annoncé qu’il n’y avait pas d’erreur et l’a installé

• Impossible de savoir s’il exécute réellement le code, ou si le LLM devine le résultat d’exécution et l’affiche

• Comme cela s’exécute dans un conteneur verrouillé, il n’y a aucune raison de le limiter à Python

  • Ils devraient tout autoriser, comme avec Replit
  • Je me demande pourquoi ils utilisent un vieux Linux
  • « Leur sandbox utilise un ancien noyau Linux de 2016 »

• Voilà comment ils mettent en œuvre le « Open » dans « OpenAI »

  • Ce serait génial si on pouvait obtenir les poids de cette manière

• Merci pour cet article intéressant

  • Je ne lis pas habituellement les articles sur l’IA, mais j’aime beaucoup celui-ci d’un point de vue technique
  • C’est pénible à lire sur Twitter à cause des pop-ups

• Exemple où Simonw a expérimenté avec C dans ChatGPT il y a un an

  • Je pense que ChatGPT et Claude sont très bons en C

• J’ai fait quelque chose de similaire l’an dernier et j’ai aussi essayé d’exécuter des binaires arbitraires

  • C’était aussi possible dans GPT, mais à l’époque ce n’était pas très fiable
  • Les nouveaux modèles semblent mieux suivre les prompts, donc je vais réessayer

• La peur d’un échec de sécurité est telle que je n’envisagerais même pas de publier ce genre d’application en ligne

  • Je finis par poser beaucoup trop de questions liées au jailbreak
  • Mais certaines personnes acceptent ce risque

• C’est vraiment très cool, et ce serait aussi intéressant d’essayer d’autres choses, comme lancer un daemon C++ ou l’ajouter à cron