Le correctif d’août d’OpenAI pour le vol de traces de raisonnement a été rapidement contourné

La société de recherche en cybersécurité Xint a publié lundi les détails d’un bug dans l’API OpenAI qui divulgue des traces de raisonnement brutes à partir de modèles OpenAI frontières, révélant le risque d’autres fuites de données. OpenAI a confirmé la faille, l’a atténuée et a payé une prime de bug pour sa découverte.

Le problème est qu’OpenAI avait déjà déployé des mesures d’atténuation pour résoudre le problème en août après qu’un rapport de recherche intitulé Stolen Thoughts ait révélé un bug similaire qui permettait le vol de traces de raisonnement, avec des conséquences possibles, notamment l’extraction de données à grande échelle et la possibilité pour les attaquants d’exécuter des injections d’invites invisibles et d’intégrer des charges utiles malveillantes pour empoisonner les déploiements d’agents publics. La découverte de Xint a contourné ces atténuations.

OpenAI n’a pas répondu à une demande de commentaire.

La correction de correctifs comme celui-ci commence à devenir une tendance parmi les principaux fournisseurs d’IA, AWS ayant signalé plus tôt ce mois-ci qu’il avait corrigé un bug en avril, pour ensuite devoir le corriger en septembre.

Contourner l’atténuation

Xint décrit le trou actuel comme une contrebande de compactage. Son article de blog sur la faille décrivait la méthodologie de ses chercheurs.

« Notre nouvelle technique, la contrebande de compactage, déplace le raisonnement d’un modèle vers un autre modèle en l’encodant dans un compactage », ont-ils écrit.

Premièrement, ils ont capturé le raisonnement crypté d’une tâche désignée, supprimé la tâche d’origine de l’historique et conservé le raisonnement textuellement.

Ensuite, « nous avons demandé le raisonnement sous une clé « solution » dans un objet JSON, avec chaque espace remplacé par une tabulation (t), ce qui était suffisant pour échapper aux classificateurs de politique d’utilisation d’OpenAI », indique le message. « Les éléments de compactage chiffrés sont toujours portables, nous avons donc envoyé l’élément de compactage à gpt-4.1 et gpt-4o et avons demandé à chacun d’afficher son entrée exactement telle quelle, ce qu’ils ont fait avec plaisir. Nous avons ensuite décodé le JSON et reconverti les onglets en espaces. « 

Le message ajoute que la tactique a fonctionné « parce que les atténuations d’OpenAI d’août bloquent uniquement la relecture du raisonnement dans un modèle différent, et l’appel de compactage s’exécute sur le même modèle qui a produit le raisonnement. L’attaque a fonctionné à chaque effort de raisonnement que nous avons essayé. »

Un problème difficile à résoudre

Tim Becker, chercheur principal chez Xint et auteur du billet de blog, a déclaré dans une interview qu’une partie de la chronologie de la faille était inconnue. Par exemple, la publication Stolen Papers a été mise en ligne le 10 août, mais Becker sait seulement qu’OpenAI a résolu ce problème à un moment donné avant cette date. Et, a-t-il déclaré, OpenAI n’a pas publié la mise en œuvre du correctif pour le problème signalé par Xint ; contrairement aux correctifs traditionnels, un modéliste IA peut apporter des modifications en silence. « C’est une sorte de sécurité par l’obscurité », a-t-il déclaré, utilisant un terme qui, historiquement, signifiait que quelque chose n’était protégé que par le fait que presque personne ne connaissait son existence.

Selon Becker, la protection d’un tel modèle « est un problème fondamentalement difficile à résoudre », principalement en raison du nombre massif de changements que subissent régulièrement les modèles actuels.

Les modèles « sont une cible mouvante et cela fait partie du problème. Toute atténuation sera quelque peu fragile », a-t-il déclaré.

De plus, Frank Dickson, analyste principal chez Dickson Research, a souligné que les modèles d’IA ont tendance à se nourrir d’eux-mêmes sur le plan opérationnel, raison pour laquelle la méthode de Xint a fonctionné.

« Le compactage fonctionne sur le même modèle qui a produit le raisonnement, il a donc dépassé l’atténuation d’août, qui a seulement bloqué la répétition du raisonnement dans un modèle différent », a-t-il déclaré. « Échanger des espaces contre des onglets était suffisant pour échapper aux classificateurs de politique d’utilisation. Le coffre-fort était verrouillé. L’employé qui détenait la clé lisait toujours la lettre à haute voix si vous le demandiez gentiment. OpenAI a corrigé le bug qui lui était affiché. Le problème est qu’une seule porte lui était montrée. « 

Risque pour les entreprises

Les analystes et les consultants estiment qu’il s’agit d’un gros problème immédiat pour les principaux fournisseurs d’IA, mais qu’il existe un risque secondaire évident pour les RSSI d’entreprise.

Erik Avakian, conseiller technique chez Infotech, a déclaré que l’équipe Xint « a contourné les protections en utilisant des fonctionnalités légitimes déjà intégrées à la plate-forme. Pour la plupart des entreprises, même si cette découverte spécifique ne peut pas atteindre le niveau d’une crise immédiate, son importance est qu’elle démontre comment les fonctionnalités légitimes de la plate-forme d’IA peuvent être combinées pour contourner des protections étroitement conçues. « 

« Cela peut exposer les organisations à des risques que le correctif individuel d’un fournisseur ne peut pas entièrement répondre », a-t-il déclaré. «Cela renforce à quel point il peut être difficile de remédier pleinement à ces vulnérabilités dans des situations où les différents composants d’un système d’IA interagissent de manière à créer des risques involontaires.»

Avakian a déclaré que cela devrait être un avertissement pour l’entreprise.

« Pour les RSSI, ce qu’il faut retenir, c’est que le correctif d’un fournisseur pour un exploit spécifique ne doit pas, en soi, être traité comme une preuve que la faiblesse sous-jacente a été entièrement corrigée », a-t-il déclaré. « Les RSSI devraient faire pression sur leurs fournisseurs d’IA pour qu’ils expliquent non seulement comment un exploit signalé a été corrigé, mais également comment ils ont été testés sur les fonctionnalités et services interconnectés. »

Brian Levine, associé du cabinet de conseil Control Risks, a ajouté qu’il pense que les RSSI devraient examiner l’ensemble des failles comme celles-ci qui doivent être corrigées à plusieurs reprises.

« Les fournisseurs corrigent le chemin d’attaque spécifique qui a été signalé, et non la classe de faiblesse sous-jacente, et les chercheurs reviennent directement par une porte latérale », a-t-il déclaré. « Une notification de correctif ne prouve pas que le risque a disparu. Arrêtez de considérer le « réparé » d’un fournisseur d’IA comme la fin de la conversation. Demandez quelles variantes de tests ont été effectuées et intégrez une notification de régression dans vos contrats. « 

Jeff Valdes, directeur du cabinet de conseil Acceligence, partageait des craintes similaires.

« C’est ce qui se produit lorsque vous traitez la sécurité comme un jeu de taupe au lieu de réparer la plomberie sous-jacente », a déclaré Valdes. « Corriger un symptôme tout en laissant les canaux d’assistance grands ouverts n’est pas une stratégie de correction. Il s’agit simplement de repousser la vulnérabilité jusqu’à la prochaine version. Si un attaquant peut faire passer clandestinement le bloc-notes interne du modèle au-delà des limites de l’API pour voler des données de formation, qu’est-ce qui fait penser que les invites de l’entreprise et le contexte intermédiaire sensible sont véritablement mis en quarantaine ? »

De plus, Pieter Arntz, chercheur en intelligence malveillante chez Malwarebytes, a observé que le correctif OpenAI de cet été était inadéquat. « Les mesures d’atténuation précédentes étaient incomplètes, ce qui constitue une description juste d’un écart », a déclaré Arntz.

« Retestez après les correctifs du fournisseur », a-t-il conseillé. « Comme le montre le cas AWS, un correctif à un endroit peut laisser d’autres voies ouvertes. Vérifiez avec vos propres tests plutôt que de vous fier aux paroles du fournisseur. « 

Aman Mahapatra, directeur de la stratégie de la société de conseil en technologie Tribeca Softech, basée à New York, a déclaré qu’il était presque impossible pour les plus grands fournisseurs d’IA d’aborder ces grands rapports de manière fragmentaire.

« Les fournisseurs d’IA corrigent des exploits sur une surface qui augmente de plusieurs fonctionnalités par mois », a-t-il souligné. « Jusqu’à ce qu’ils corrigent les propriétés plutôt que les chemins, les RSSI devraient supposer que chaque correctif de sécurité de l’IA est partiel, que chaque blob chiffré est lisible et que chaque garde-fou du fournisseur n’est qu’une astuce d’encodage non pertinente. La tendance est réelle, et « le correctif n’a pas fonctionné » sous-estime ce qui se passe. « 

Il a noté que, dans les cas OpenAI et AWS, le fournisseur a corrigé la preuve de concept et a laissé la propriété intacte. « Réparez le chemin, gardez la propriété », a-t-il déclaré. « Sur les plates-formes assemblées à partir de fonctionnalités composables, chaque nouvelle fonctionnalité est un nouveau chemin vers le même actif, et les points fixes sur une surface combinatoire continueront à perdre. »

Des RSSI peu habitués au modèle agent

Mahapatra a déclaré que l’industrie de la cybersécurité devrait tirer les leçons de sa propre histoire.

« Les cryptographes l’ont appris il y a vingt ans avec les oracles de remplissage : tout système qui déchiffre pour le compte d’un client et renvoie tout ce qui dérive du texte brut est un oracle. Les plates-formes d’IA le réapprennent avec une touche particulière », a-t-il déclaré. « Chaque étape du LLM qui permet de voir un secret et d’accepter des instructions est un oracle, et le langage naturel est l’interface oracle la plus expressive jamais construite. »

Il a noté que le compactage faisait exactement ce pour quoi il avait été conçu et que sa portabilité entre les modèles existait, de sorte que des outils agents tels que Codex pouvaient permettre aux utilisateurs de changer de modèle en cours de session. « La fonctionnalité et la vulnérabilité sont la même capacité, c’est pourquoi les correctifs continuent d’arriver », a-t-il déclaré.

Mais, a-t-il soutenu, le plus gros problème est que les opérations des RSSI ne sont pas encore habituées à la manière de faire les choses du modèle agent.

« Les failles de la plateforme d’IA arrivent sans CVE, sans avis et sans notes de mise à jour. La gestion des vulnérabilités d’entreprise, basée sur les flux CVE et les avis des fournisseurs, est aveugle aux nouveaux fournisseurs les plus importants », a déclaré Mahapatra. « Les RSSI devraient inscrire des obligations de notification de sécurité dans les contrats des fournisseurs d’IA, désigner quelqu’un pour suivre les divulgations des chercheurs par rapport aux plates-formes qu’ils utilisent et poser une question après chaque correctif du fournisseur : avez-vous corrigé le rapport ou la classe, et quelle analyse de variantes soutient cette réponse ?

Il a également soulevé des questions sur le faible montant de la prime versée à Xint.

« Une prime de 6 000 $ pour un bug permettant exactement la distillation à l’échelle industrielle contre laquelle la NSA, la CISA et le FBI avaient mis en garde dans un avis conjoint en septembre est un signal de prix que les chercheurs avec d’autres acheteurs remarqueront », a-t-il déclaré.