nouvelles

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Nouveau rapport de sagesse

Editeur : Er Qiao Yang

[Introduction à la nouvelle sagesse]Apple Intelligence est sur le point d'être mis en ligne, mais quelques lignes de code ont révélé une faille de sécurité dans Apple Intelligence.

Lors de la Worldwide Developers Conference (WWDC) 2024, Apple a publié la fonctionnalité d'IA Apple Intelligence qui sera incluse dans iOS 18.1.

Voyant qu'il s'apprête à être officiellement lancé en octobre, un « expert privé » a découvert une faille majeure dans la version bêta test d'Apple Intelligence fournie par MacOS 15.1.

Le développeur Evan Zhou a manipulé avec succès Apple Intelligence en utilisant l'injection rapide, en contournant les instructions attendues et en permettant à l'IA de répondre à des invites arbitraires.

Il s'avère que, comme d'autres systèmes d'IA basés sur de grands modèles de langage, il est vulnérable aux « attaques par injection de mots indicateurs ». Le développeur Evan Zhou a démontré cette vulnérabilité dans une vidéo YouTube.

Qu’est-ce qu’une attaque par injection de mots rapides ?

Il existe une organisation appelée OWASP, qui est l'Open Global Application Security Project. Ils ont analysé les principales vulnérabilités auxquelles les grands modèles de langage peuvent être confrontés. Devinez ce qu’ils ont classé n°1 ? C'est vrai, c'est une injection de mots rapide.

L'attaque par injection rapide est un nouveau type d'attaque sous différentes formes, notamment l'injection de mots rapides, la fuite de mots rapides et le jailbreak de mots rapides.

Cette attaque se produit lorsqu'un attaquant manipule l'intelligence artificielle pour amener le modèle à effectuer des actions inattendues ou à divulguer des informations sensibles. Cette manipulation peut permettre à l'IA d'interpréter à tort des entrées malveillantes comme des commandes ou des requêtes légitimes.

Avec l'utilisation généralisée des grands modèles de langage (LLM) par les particuliers et les entreprises et les progrès continus de ces technologies, la menace d'attaques par injection d'indices augmente considérablement.

Alors, comment est-ce arrivé en premier lieu ? Pourquoi les systèmes sont-ils vulnérables à ce type d’attaque ?

En fait, dans les systèmes traditionnels, les développeurs prédéfiniront les programmes et les instructions, et ceux-ci ne changeront pas.

Les utilisateurs peuvent saisir leurs informations, mais le code et la saisie du programme restent séparés.

Cependant, ce n’est pas le cas pour les grands modèles linguistiques. Autrement dit, la frontière entre les instructions et les entrées devient floue car les grands modèles utilisent souvent des entrées pour entraîner le système.

Par conséquent, l’encodage et la saisie de grands modèles de langage n’ont pas de limites aussi claires et sans ambiguïté que par le passé. Cela lui donne beaucoup de flexibilité, mais aussi la possibilité pour le modèle de faire des choses qu'il ne devrait pas faire.

Bruce Schneier, expert technique en sécurité et maître de conférences à la Harvard Kennedy School, a publié en mai un article dans Communications of the ACM qui traitait en détail de la question de sécurité du LLM. Selon lui, cela vient du fait de « ne pas séparer les chemins de données et de contrôle ».

Les attaques par injection de mots rapides peuvent entraîner des fuites de données, générer du contenu malveillant et diffuser des informations erronées, entre autres conséquences.

Les attaques par injection d'indices se produisent lorsqu'un attaquant construit intelligemment des instructions d'entrée pour manipuler un modèle d'IA, l'incitant ainsi à révéler des informations confidentielles ou sensibles.

Ce risque est particulièrement aigu dans les modèles formés sur des ensembles de données contenant des données propriétaires ou personnelles. Un attaquant exploiterait les capacités de traitement du langage naturel du modèle pour formuler des instructions qui semblent inoffensives à première vue, mais qui sont en réalité conçues pour extraire des informations spécifiques.

Avec une planification minutieuse, un attaquant peut tromper un modèle pour qu'il génère une réponse contenant des informations personnelles, les opérations internes d'une entreprise et même des protocoles de sécurité intégrés dans les données d'entraînement du modèle.

Ce type de violation de données porte non seulement atteinte à la vie privée, mais constitue également une menace de sécurité importante pouvant entraîner des pertes financières potentielles, des atteintes à la réputation et des litiges juridiques.

Pour revenir au cas de Zhou, le but de Zhou est de manipuler la fonction de « réécriture » d'Apple Intelligence, c'est-à-dire de réécrire et d'améliorer le texte saisi par l'utilisateur.

Au cours de l'opération, Zhou a découvert qu'une simple commande « ignorer la commande précédente » avait en fait échoué.

S'il s'agit d'un LLM « hermétique », il sera relativement difficile de continuer à creuser. Mais par coïncidence, le modèle d’invite d’Apple Intelligence a récemment été découvert par les utilisateurs de Reddit.

À partir de ces modèles, Zhou a découvert un jeton spécial utilisé pour séparer le rôle du système d'IA et le rôle de l'utilisateur.

En utilisant ces informations, Zhou a créé une invite qui a remplacé l'invite système d'origine.

Il a mis fin au rôle d'utilisateur plus tôt, a inséré une nouvelle invite système, demandant à l'IA d'ignorer les instructions précédentes et de répondre au texte suivant, puis a déclenché la réponse de l'IA.

Après quelques expérimentations, l’attaque a réussi : Apple Intelligence a répondu avec des informations que Zhou n’avait pas demandées, ce qui signifie que l’attaque par injection rapide a fonctionné. Zhou a publié son code sur GitHub.

Un utilisateur de Twitter brise GPT-3

Le problème d’injection de pointe est connu depuis au moins la sortie de GPT-3 en mai 2020, mais reste non résolu.

Remoteli.io, un bot basé sur l'API GPT-3, a été victime de cette vulnérabilité sur Twitter. Le bot doit publier automatiquement des tâches à distance et répondre aux demandes de tâches à distance.

Cependant, avec l'invite ci-dessus, le robot Remoteli est devenu la cible de plaisanteries parmi certains utilisateurs de Twitter : ils ont forcé le robot à prononcer des phrases qu'il n'aurait pas prononcées selon ses instructions initiales.

Par exemple, le robot menace les utilisateurs d’assumer l’entière responsabilité du désastre de la navette spatiale Challenger, ou dénigre les membres du Congrès américain en les qualifiant de tueurs en série.

Dans certains cas, le robot diffuse de fausses nouvelles ou publie du contenu qui enfreint les politiques de Twitter, ce qui devrait entraîner son expulsion.

Le data scientist Riley Goodside a été le premier à prendre conscience du problème et l'a décrit sur Twitter.

En insérant des indices dans les phrases à traduire, Goodside a démontré à quel point les robots de traduction basés sur GPT-3 sont vulnérables.

L'informaticien britannique Simon Willison a discuté en détail de ce problème de sécurité sur son blog, le qualifiant d'« injection rapide ».

Willison a découvert que les instructions d'injection d'indices des grands modèles de langage pouvaient provoquer toutes sortes de choses étranges et potentiellement dangereuses. Il continue en décrivant divers mécanismes de défense mais les rejette finalement. Actuellement, il ne sait pas comment fermer de manière fiable la faille de sécurité de l’extérieur.

Bien entendu, il existe des moyens d'atténuer ces vulnérabilités, par exemple en utilisant des règles qui recherchent des modèles dangereux dans les entrées des utilisateurs.

Mais rien n’est sûr à 100 %. Chaque fois qu'un grand modèle de langage est mis à jour, les mesures de sécurité prises doivent être réexaminées, a déclaré Willison. De plus, quiconque sait écrire une langue est un attaquant potentiel.

"Les modèles de langage comme GPT-3 sont la boîte noire ultime. Peu importe le nombre de tests automatisés que j'écris, je ne peux jamais être sûr à 100 % que l'utilisateur ne trouvera pas des mots-indices auxquels je ne m'attendais pas, qui renverser mes défenses", a écrit Willison.

Willison estime que la séparation des entrées de commande et des entrées utilisateur est une solution possible, à savoir la « séparation des chemins de données et de contrôle » mentionnée dans l'article ACM mentionné ci-dessus. Il pense que les développeurs seront éventuellement en mesure de le comprendre, mais il aimerait voir des recherches prouvant que cette approche fonctionne réellement.

Certaines entreprises ont le mérite d’avoir pris des mesures pour rendre les attaques par injection de pourboires relativement difficiles.

Lorsque Zhou a piraté Apple Intelligence, il a également dû trouver un jeton spécial via le modèle d'invite back-end ; dans certains systèmes, les attaques par injection d'invite peuvent être aussi simples que l'ajout du texte correspondant dans la fenêtre de discussion ou dans l'image d'entrée.

En avril 2024, OpenAI a lancé la méthode de hiérarchie d'instructions comme contre-mesure. Il attribue différentes priorités aux instructions des développeurs (priorité la plus élevée), des utilisateurs (priorité moyenne) et des outils tiers (priorité faible).

Les chercheurs ont fait la distinction entre les « instructions alignées » (correspondant à des instructions de priorité plus élevée) et les « instructions non alignées » (contredisant des instructions de priorité plus élevée). En cas de conflit d’instructions, le modèle suit l’instruction de priorité la plus élevée et ignore les instructions de priorité inférieure en conflit.

Même avec des contre-mesures en place, des systèmes comme ChatGPT ou Claude sont toujours vulnérables à l'injection de pourboires dans certains cas.

LLM possède également une vulnérabilité "injection SQL"

En plus des attaques par injection de mots rapides, Andrej Karpathy a récemment signalé une autre vulnérabilité de sécurité dans LLM sur Twitter, qui équivaut à une « attaque par injection SQL » traditionnelle.

Lorsque le tokeniseur LLM analyse le jeton spécial de la chaîne d'entrée (tel que :<|endoftext|>etc.), même si la saisie directe peut sembler pratique, elle peut, au mieux, causer des problèmes ou, au pire, des problèmes de sécurité.

Ce qu’il faut garder à l’esprit à tout moment, c’est que les chaînes saisies par l’utilisateur ne sont pas fiables ! !

Tout comme les attaques par injection SQL, les pirates peuvent faire en sorte qu'un modèle se comporte de manière inattendue grâce à des entrées soigneusement construites.

Karpathy a ensuite fourni un ensemble d'exemples sur Huggingface utilisant les valeurs par défaut du tokenizer Llama 3, et a découvert deux choses étranges :

1、<|beginoftext|>le jeton (128 000) est ajouté au début de la séquence ;

2. Analyser à partir de la chaîne<|endoftext|> Marqué d'un jeton spécial (128001). La saisie de texte par l'utilisateur peut désormais perturber la spécification du jeton, provoquant une sortie de modèle incontrôlée.

À cet égard, Karpathy a fait deux suggestions :

Utilisez toujours deux valeurs d'indicateur supplémentaires, (1) add_special_tokens=False et (2) split_special_tokens=True, et ajoutez vous-même des jetons spéciaux dans le code.

Pour les modèles de chat, vous pouvez également utiliser le modèle de chat apply_chat_template.

Selon la méthode de Karpathy, les résultats de la segmentation des mots en sortie semblent plus corrects,<|endoftext|> Traitée comme une chaîne arbitraire plutôt que comme un jeton spécial, et divisée par le tokenizer BPE sous-jacent comme n'importe quelle autre chaîne :

En résumé, Karpathy estime que les appels de codage/décodage ne devraient jamais analyser les chaînes pour gérer des jetons spéciaux, et que cette fonctionnalité devrait être complètement obsolète et ajoutée uniquement explicitement par programme via un chemin de code distinct.

À l’heure actuelle, ces problèmes sont difficiles à trouver et sont rarement documentés. On estime qu’environ 50 % du code actuel présente des problèmes liés.

De plus, Karpathy a découvert que même ChatGPT présente ce bug.

Dans le meilleur des cas, il supprime simplement le jeton spontanément. Dans le pire des cas, LLM ne sera pas en mesure de comprendre ce que vous voulez dire et ne pourra même pas répéter la sortie conformément aux instructions.<|endoftext|> Cette chaîne :

Certains internautes ont soulevé des questions dans la zone de commentaires. Si le code est écrit correctement, mais que les données de formation sont saisies.<|endoftext|> ce qui se produit?

Karpathy a répondu que si le code est correct, rien ne se passera. Le problème est qu'une grande partie du code peut ne pas être correcte, ce qui peut discrètement casser leur LLM.

Enfin, afin d'éviter les problèmes de sécurité causés par les vulnérabilités LLM, Karpathy rappelle à tous : vous devez visualiser votre token et tester votre code.

Références :

https://the-decoder.com/apple-intelligence-in-macos-15-1-beta-1-is-vulnerable-to-a-classic-ai-exploit/