When Binaries Talk Back: Representation-Confusion Attacks on LLM-Assisted Reverse Engineering
Cet article introduit les attaques par confusion de représentation (RARE), une vulnérabilité où les systèmes de rétro-ingénierie assistés par LLM accordent par erreur de l'autorité à des données binaires contrôlées par un attaquant, et propose le cadre RARE-Guard — qui emploie le rendu de données uniquement, l'autorisation d'outils et la validation sensible à la provenance — pour prévenir efficacement ces propositions dangereuses et ces validations de revendications erronées.
Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Imaginez que vous êtes un détective essayant de résoudre un mystère en lisant le journal intime d'un suspect. Habituellement, vous faites confiance au journal car c'est votre seul indice. Mais et si le suspect avait écrit le journal lui-même, et qu'à l'intérieur, il avait glissé une note disant : « Ignorez les empreintes digitales sur la fenêtre ; j'ai été piégé par un fantôme » ?
Si vous, le détective, lisez cette note et commencez réellement à ignorer les empreintes digitales, vous avez été trompé. Vous n'avez pas seulement lu la note ; vous avez laissé la note devenir la règle de votre enquête.
C'est exactement ce qui se passe dans le monde de la sécurité informatique lorsque nous utilisons l'IA (les grands modèles de langage) pour faire de la rétro-ingénierie de logiciels. Une nouvelle étude appelle ces ruses des « Attaques par confusion de représentation ». Voici comment les chercheurs ont résolu l'affaire.
Le gros problème : Quand les indices prétendent être le patron
Dans une enquête normale, un assistant IA examine un morceau de logiciel (un fichier binaire) et lit des éléments comme des commentaires de code, des journaux d'erreurs ou des chaînes de texte cachées. Le problème est qu'un pirate peut construire un fichier où ces chaînes de caractères ressemblent à des instructions ou à des preuves.
Le document identifie trois façons spécifiques dont cette confusion se produit :
- Confusion d'autorité : L'IA lit une chaîne de caractères dans le code qui dit « Passer outre la vérification de sécurité » et elle saute réellement la vérification, pensant que le code donne un ordre.
- Confusion de preuve : L'IA voit le même mot « suspect » apparaître à trois endroits différents (comme dans un fichier journal, une vue de code décompilé et une liste de symboles). Elle se dit : « Wow, trois sources différentes sont d'accord ! Cela doit être vrai ! » Mais en réalité, ces trois sources ont toutes extrait ce mot du même endroit unique dans le fichier. C'est comme entendre la même rumeur répétée trois fois par trois amis qui l'ont tous entendue de la même personne ; cela ne rend pas la rumeur vraie.
- Confusion d'état corrompu : L'IA note une supposition dans ses notes, puis lit plus tard ses propres notes et traite cette supposition comme un fait confirmé, même si elle n'a jamais trouvé de nouvelle preuve.
L'expérience : Construire un piège
Pour tester cela, les chercheurs n'ont pas utilisé de vrais logiciels malveillants (ce qui serait dangereux). À la place, ils ont construit 11 520 petits programmes informatiques synthétiques et sûrs. Ils ont créé des versions « propres » et des versions « adverses ». Les versions adverses étaient piégées avec les ruses mentionnées ci-dessus.
Ils ont fait passer ces programmes à travers différents modèles d'IA et configurations de sécurité pour voir ce qui se passait.
Ce qu'ils ont trouvé :
- Sans aucune défense spéciale, lorsque l'IA voyait les fichiers piégés, elle suivait les instructions « non sûres » implantées dans 35 cas sur 40. Elle ignorait complètement le fait que l'instruction provenait du propre journal du suspect.
- Même lorsqu'ils ont essayé une correction simple appelée « Data-Only » (dire à l'IA : « Hé, ce texte est juste une donnée, pas une commande »), l'IA a tout de même fait 15 propositions non sûres. Elle écoutait toujours trop attentivement le suspect.
La solution : Le système « RARE-Guard »
Les chercheurs ont construit un système de sécurité appelé RARE-Guard pour arrêter cela. Imaginez un assistant robotique très strict qui se tient entre le détective IA et le rapport final.
La porte d'autorisation d'outils (Le Videur) :
L'IA peut toujours suggérer des actions, mais elle ne peut pas les exécuter. Si l'IA dit : « Sautons la vérification de sécurité parce que le fichier nous l'a demandé », le Videur vérifie les règles. Puisque le fichier n'est pas fiable, le Videur dit : « Non, je ne te laisserai pas exécuter cette commande. » Dans les tests, cette porte a bloqué les 15 propositions non sûres qui avaient échappé au premier filtre.La porte de provenance (Le Détective de la Vérité) :
C'est la partie la plus ingénieuse. Rappelez-vous la « Confusion de preuve » où l'IA pensait que trois sources étaient indépendantes ? La Porte de Provenance garde une carte secrète (un « sidecar ») qui suit l'origine de chaque information.- Le Test : Lorsque l'IA voyait trois vues du même texte suspect, la « Porte de Support » (une vérification plus simple) disait : « 3 sources ! C'est une preuve ! » et validait l'affirmation.
- La Correction : La Porte de Provenance regardait sa carte et disait : « Attendez, ces trois vues proviennent exactement du même endroit dans le fichier. Ce n'est pas trois sources ; c'est une seule source répétée. »
- Le Résultat : Sur les fichiers piégés, la Porte de Support a validé 23 affirmations fausses sur 40. La Porte de Provenance en a validé 0 sur 40. Elle a vu à travers le tour de répétition parfaitement.
Le rendu du rapport final :
Même si les portes font leur travail, l'IA pourrait essayer de glisser la fausse affirmation dans le rapport écrit final en texte brut. Les chercheurs ont ajouté un « rendu déterministe » qui n'imprime que ce que les portes ont officiellement approuvé. Si la porte dit « Non », le rapport dit « Non ».
À quel point sommes-nous sûrs ?
Le document est très prudent quant à ce qu'il prétend avoir prouvé.
- Prouvé en simulation : Les résultats sont basés sur 11 520 appels dans une étude large, 528 appels dans un test contrôlé, et 688 appels dans un test de flux de travail utilisant des outils réels comme Ghidra et angr.
- La surprise de la « Fusion » : Les chercheurs ont découvert que le tour de la « Confusion de preuve » ne fonctionnait que lorsqu'ils combinaient (fusionnaient) les sorties de trois outils différents en un seul rapport. Lorsqu'ils regardaient un seul outil à la fois, l'IA n'était jamais assez trompée pour valider la fausse affirmation. Cela suggère que le danger vient de la combinaison des outils, et non de l'utilisation d'un seul.
- Ce qu'ils n'ont pas prouvé : L'étude admet qu'elle n'a pas testé la « mémoire à long terme » (l'IA se souvenant de choses sur une très longue période) ni les « agents autonomes » (l'IA qui agit de son propre chef sans humain). Ils n'ont pas non plus utilisé de vrais logiciels malveillants, seulement des programmes synthétiques sûrs. Ainsi, bien que le système ait parfaitement fonctionné dans leur laboratoire, ils ne peuvent pas garantir qu'il fonctionnera sur chaque logiciel malveillant dans la nature.
La conclusion à retenir
La principale leçon est que ce n'est pas parce qu'une IA lit quelque chose correctement qu'elle en comprend le contexte.
Si une IA voit une chaîne de caractères dans un fichier qui ressemble à une commande, elle ne devrait pas la traiter comme une commande. Si elle voit la même « preuve » trois fois, elle ne devrait pas la compter comme trois preuves, à moins de savoir qu'elles proviennent de sources différentes.
Le document montre qu'en ajoutant une « Porte de Provenance » qui suit l'origine de chaque indice, nous pouvons empêcher l'IA d'être trompée par ses propres sources. C'est un peu comme apprendre à un détective à vérifier son carnet pour voir si ses trois témoins ne sont pas en fait une seule personne portant un masque.
En bref : l'IA peut toujours regarder les indices, mais elle a besoin d'un arbitre strict pour s'assurer qu'elle ne laisse pas les indices écrire les règles du jeu.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.