REA n'est pas un sandbox : confiner l'analyse d'un binaire inconnu

La politique de sécurité du projet REA (Reverse Engineer Anything) contient une phrase que tout RSSI devrait lire avant d'installer l'outil : « This is not a sandbox and does not protect against malicious processes already running as the same operating-system user »¹. Le fichier SECURITY.md ajoute qu'ouvrir un binaire non fiable confie son analyse au moteur local choisi, avec les permissions de l'utilisateur. Le serveur MCP, qui affichait 76 998 étoiles sur GitHub le 11 octobre 2026, ne vous protège donc pas du binaire que vous lui donnez². Voici ce que REA isole, ce qu'il laisse passer, et la manière de confiner l'analyse.

Ce que le pont authentifié protège

REA pilote des moteurs de décompilation installés sur votre poste (Hopper, Ghidra ou IDA) à travers un pont (l'architecture est décrite dans REA expliqué en trois schémas). Les mainteneurs ont soigné ce pont : chaque session reçoit un jeton de capacité aléatoire, transmis par un descripteur privé plutôt que par les arguments du processus ou les variables d'environnement. Sous Linux et macOS, le pont passe par un socket Unix réservé à l'utilisateur courant ; sous Windows, Ghidra communique en TCP local authentifié, dans un répertoire NTFS dont les droits n'admettent que l'utilisateur et SYSTEM¹.

Les sessions Ghidra tournent dans un projet temporaire isolé, avec des répertoires privés, des limites de processeur et de mémoire, et le projet est supprimé à la fermeture. Le texte précise lui-même la portée de ces contrôles : ils limitent la persistance accidentelle et la consommation de ressources, sans faire de Ghidra un bac à sable¹. Un programme tiers qui voudrait parler au pont sans jeton est rejeté. Un programme malveillant qui tourne déjà sous votre compte, ou un fichier piégé qui exploite une faille du moteur d'analyse, passe à côté de cette frontière.

Le vrai risque : vos droits, et ce que lit l'agent

Le premier risque tient au moteur. Quand vous demandez à un agent d'analyser un exécutable inconnu, Ghidra ou Hopper en parse les octets avec vos droits sur la machine : vos clés SSH, vos jetons de cloud, vos dépôts de code sont à portée. Le README va plus loin pour les fonctions d'observation à l'exécution : la capture lance la cible ou interagit avec elle avec les permissions de l'utilisateur³. Le DISCLAIMER du projet demande d'utiliser « un environnement approprié » pour les cibles non fiables et rappelle qu'une exécution locale ne garantit pas l'absence d'effets externes⁴.

Le second risque tient à l'agent lui-même. Un binaire peut contenir des chaînes rédigées comme des instructions, et un modèle qui lit la sortie du décompilateur peut les suivre. Brian Crawford et Patrick McClure ont étudié ce scénario dans un article déposé sur arXiv le 29 mai 2026 : des injections de prompt cachées dans le code d'un exécutable amènent un agent de rétro-ingénierie à décrire un comportement qui n'est pas celui du programme, avec GhidraMCP comme montage d'exemple⁵. Les auteurs proposent des méthodes de détection dans la sortie du décompilateur. En pratique, gardez l'approbation des outils active et relisez ce que l'agent veut exécuter.

Comment confiner

L'analyse statique d'un binaire dont vous connaissez l'origine peut se faire sur un poste de travail, avec prudence. L'exécution, la capture à l'exécution ou l'analyse d'un binaire inconnu ne se font jamais sur la machine principale.

Pour tout ce qui sort du cas simple, travaillez dans une machine virtuelle ou un conteneur jetable : système de fichiers en lecture seule, aucun dossier ni presse-papiers partagé, instantané que vous pouvez restaurer, et aucun secret de l'entreprise dans l'environnement. Le guide communautaire publié le 12 octobre dans les discussions du dépôt, écrit par un amateur qui teste REA, soulève une contrainte souvent oubliée : un modèle hébergé a besoin d'internet, donc la VM reste en ligne, et c'est précisément pour cela que l'échantillon ne doit jamais être lancé⁶. Si l'analyse porte sur du code sensible, un modèle exécuté localement permet de couper le réseau pour de bon.

Mise à jour du 19 octobre 2026. Une image Docker communautaire, psyb0t/docker-reverse-engineer-anything, publiée le 18 octobre en version 0.1.1, illustre cette posture⁷. En serveur MCP, son exemple utilise --read-only, --cap-drop ALL et no-new-privileges, publie l'endpoint sur 127.0.0.1 et le protège par un jeton. Le réseau n'est coupé (--network none) que dans l'exemple en ligne de commande. Elle embarque JADX, Apktool et adb, mais pas Ghidra. Il s'agit d'un projet non officiel, créé la veille : prenez-le comme modèle de configuration, pas comme une brique à déployer telle quelle. La configuration de Docker reste votre responsabilité.

Pour les échantillons hostiles, la méthode détaillée est dans analyser un malware en local avec un agent. Pour un binaire fournisseur, voir auditer un binaire fournisseur sans son code source. Et avant même de confiner, vérifiez ce que vous installez : un faux dépôt REA a distribué un cheval de Troie (faux dépôts REA et supply chain).

Ce que le confinement ne règle pas

Une VM protège votre poste. Elle ne règle ni la question des données envoyées au fournisseur du modèle, puisque REA analyse en local mais que l'agent transmet les résultats d'outils à son fournisseur, ni la question du droit d'analyser la cible. Le DISCLAIMER le rappelle : posséder un fichier ne donne pas, à lui seul, la permission de toute opération⁴. Le cadre juridique européen est présenté dans clean-room ou reverse engineering, et la vue d'ensemble pour une équipe sécurité dans rétro-ingénierie par agents et sécurité.

Questions fréquentes

REA isole-t-il l'analyse ?

Non. Le jeton de session et le socket réservé protègent le pont entre REA et le moteur d'analyse. Ils ne protègent pas votre machine d'un binaire hostile ni d'un processus malveillant qui tourne déjà sous votre compte.

Puis-je analyser un malware avec REA ?

En analyse statique, dans une VM dédiée, sans jamais lancer l'échantillon et sans utiliser les outils de capture runtime.

Une image Docker suffit-elle ?

Elle aide si elle est lancée en lecture seule, sans capacités Linux et sans réseau quand c'est possible. Une image communautaire reste à auditer comme n'importe quelle dépendance.

Faut-il couper le réseau ?

Avec un modèle hébergé, la VM doit joindre le fournisseur du modèle : d'où l'interdiction absolue d'exécuter l'échantillon. Avec un modèle local, coupez le réseau.

L'offre AI Cyber de SFEIR cadre l'usage des agents d'analyse en environnement confiné : postes, conteneurs, choix du modèle et règles d'approbation des outils.

Sources

1. morluto/rea, SECURITY.md, section « Security boundary » — github.com, consulté le 13 octobre 2026.
2. Ishank Choudhary, I Pointed REA at a 100 MB Electron App. Here's What It Found and the Two Preload Files It Missed., publié sur Medium puis sur DEV — dev.to, 12 octobre 2026.
3. morluto/rea, README, section « What you can analyze » — github.com, consulté le 13 octobre 2026.
4. morluto/rea, DISCLAIMER.md — github.com, consulté le 13 octobre 2026.
5. Brian Crawford, Patrick McClure, Investigating Detection and Obfuscation of Prompt Injection Attacks Against Software Reverse Engineering AI Agents, arXiv:2605.30677 — arxiv.org, 29 mai 2026.
6. Discussion n° 2412, New to RE with AI? What to reverse engineer first, and how to ask, guide communautaire — github.com, 12 octobre 2026.
7. psyb0t, docker-reverse-engineer-anything, release v0.1.1 — github.com, 18 octobre 2026.