Les pirates informatiques de Gemini retournent ses propres fonctions d'IA contre lui,

L'attaque Fun-Tuning atteint 80 % de réussite en exploitant le fine-tuning

L’essor des grands modèles de langage (LLM) s’accompagne de défis croissants en matière de sécurité, notamment avec l’émergence d’attaques sophistiquées exploitant leurs vulnérabilités intrinsèques. L’article examine une nouvelle méthode d’injection indirecte d’invites, baptisée Fun-Tuning, qui cible spécifiquement Gemini, le modèle propriétaire de Google. Cette approche algorithmique, contrairement aux méthodes artisanales antérieures, optimise systématiquement les attaques en exploitant les fuites d’information liées au processus de fine-tuning. Si l’efficacité de cette technique est démontrée (avec des taux de réussite dépassant 80 % sur Gemini 1.0 Pro), elle soulève des questions fondamentales sur l’équilibre entre utilité et sécurité dans les LLM fermés.

L’attaque Fun-Tuning représente une avancée technique significative dans l’exploitation des vulnérabilités des LLM, mais son analyse souffre de plusieurs lacunes méthodologiques. Premièrement, l’étude ne précise pas si les fuites d’information via les valeurs de perte sont spécifiques à Gemini ou généralisables à d’autres modèles comme GPT-4 ou Claude. Une comparaison systématique aurait permis de déterminer si cette vulnérabilité est intrinsèque au fine-tuning ou liée à une implémentation particulière. De plus, l’affirmation selon laquelle les attaques sont transférables entre Gemini 1.0 Pro et 1.5 Flash manque de profondeur : elle ne s’appuie pas sur une analyse des mécanismes internes (tels que la stabilité des embeddings ou la similarité des espaces latents), ce qui en limite la portée.


Pour la première fois, des chercheurs universitaires ont mis au point un moyen de créer des injections d'invite générées par ordinateur contre Gemini qui ont un taux de réussite beaucoup plus élevé que les injections créées manuellement. La nouvelle méthode abuse du réglage fin, une fonction offerte par certains modèles de poids fermés pour les entraîner à travailler sur de grandes quantités de données privées ou spécialisées, telles que les dossiers juridiques d'un cabinet d'avocats, les dossiers des patients ou les recherches gérées par un établissement médical, ou encore les plans architecturaux. Google met gratuitement à disposition son réglage fin pour l'API de Gemini.

Des travaux récents ont montré qu'il est possible de construire des exemples contradictoires qui amènent les modèles de langage alignés à émettre des chaînes de caractères nocives ou à adopter un comportement dangereux. Les attaques existantes fonctionnent soit en boîte blanche (avec un accès complet aux poids du modèle), soit par transférabilité : le phénomène selon lequel les exemples adverses élaborés sur un modèle restent souvent efficaces sur d'autres modèles. Les chercheurs améliorent les travaux antérieurs avec une attaque basée sur les requêtes qui exploite l'accès API à un modèle de langage distant pour construire des exemples nuisibles qui amènent le modèle à émettre des chaînes nuisibles avec une probabilité (beaucoup) plus élevée qu'avec les attaques basées uniquement sur le transfert.

Nous validons notre attaque sur GPT-3.5 et le classificateur de sécurité d'OpenAI ; nous pouvons faire en sorte que GPT-3.5 émette des chaînes nuisibles que les attaques de transfert actuelles n'atteignent pas, et nous pouvons échapper aux classificateurs de sécurité d'OpenAI et de Llama Guard avec une probabilité de près de 100 %.

Les techniques de formulation de requêtes, y compris les approches minimalistes, ne garantissent pas systématiquement les résultats souhaités. Le réglage fin (fine-tuning) constitue une méthode puissante pour améliorer les performances d'un modèle sur des tâches spécifiques ou pour le conformer à des exigences de sortie précises, notamment lorsque les instructions seules s'avèrent insuffisantes et qu'un ensemble d'exemples illustratifs est disponible.

Présentation du réglage fin avec l'API Gemini

L'objectif principal du réglage fin est d'optimiser les performances du modèle pour une application spécifique. Cette méthode implique l'utilisation d'un jeu de données contenant de nombreux exemples représentatifs de la tâche cible. Pour des domaines spécialisés, des améliorations significatives peuvent être obtenues même avec un nombre limité d'exemples (approche dite « d'apprentissage supervisé »).

Structure des données d'entraînement

Les données doivent être organisées en paires « requête-réponse attendue ». Google AI Studio permet également un réglage direct à partir d'exemples. L'objectif est d'enseigner au modèle le comportement souhaité en lui exposant systématiquement des cas concrets.

Processus d'apprentissage

Lors du réglage fin, le modèle acquiert de nouveaux paramètres lui permettant d'intégrer les spécificités de la tâche visée. Ces paramètres, combinés à ceux du modèle initial, produisent une nouvelle version spécialisée du modèle.

Préparation des données

Un jeu de données de qualité est essentiel pour un réglage efficace. Les exemples doivent être :

• Représentatifs des cas réels
• Diversifiés
• De haute qualité

Format des données

Important : Seules les paires entrée-sortie sont actuellement supportées (les conversations multi-tours ne sont pas prises en charge). La structure des données d'entraînement doit correspondre exactement au format des requêtes de production, incluant le même vocabulaire, instructions et mise en forme.

Exemple :

Si les données d'entraînement utilisent les marqueurs « question: » et « contexte: », les requêtes de production doivent impérativement suivre le même format. L'omission d'un élément, même pour une question identique à un exemple d'entraînement, compromettrait la reconnaissance par le modèle.

Considérations pratiques

Notation des invites avec biais logit et top-5 logprobs

Court-circuiter la perte

La méthode décrite précédemment calcule le logprob cumulatif d'une séquence cible conditionnée par une invite en calculant itérativement la contribution de chaque jeton au total. En pratique, nous pouvons abandonner le calcul du logprob cumulé plus tôt si nous savons qu'il est déjà suffisamment petit. C'est ce qui a motivé l'introduction de la mémoire tampon. Comme nous conservons une mémoire tampon des B meilleures invites inexplorées observées jusqu'à présent, nous savons que toute invite dont la perte est supérieure à ℓ(b_worst) sera écartée. En pratique, nous constatons que cette optimisation réduit le coût total de l'attaque d'environ 30 %.

Requête gourmande de coordonnées

Dans l'algorithme ci-dessus, les chercheurs initialisent le tampon avec des invites m - jetons aléatoires et uniformes. Cependant, dans la pratique, nous avons constaté qu'il est préférable d'initialiser la mémoire tampon avec une invite conçue spécifiquement pour obtenir la chaîne cible. En particulier, nous avons constaté que la simple répétition de la chaîne cible autant de fois que la longueur de la séquence le permet, avec une troncature à gauche, était un choix efficace pour l'invite initiale. Cette invite produit immédiatement la chaîne cible (sans qu'il soit nécessaire d'exécuter l'algorithme 1) pour 28% des chaînes dans les chaînes nuisibles lorsque m = 20.

Attaques basées sur des requêtes sans proxy

Les attaques que nous avons décrites jusqu'à présent s'appuient sur un modèle de mandataire local pour guider la recherche contradictoire. Comme nous le verrons, ces mandataires peuvent être disponibles même s'il n'existe pas de bon modèle de substitution pour les attaques basées sur le transfert uniquement. Cependant, il existe également des situations dans lesquelles un attaquant n'a pas accès à de bons modèles de substitution. Dans cette section, nous explorons la possibilité d'attaques basées sur des requêtes pures sur des modèles de langage.

Les chercheurs partent de l'observation que dans les attaques d'optimisation existantes telles que GCG, le gradient du modèle fournit un signal plutôt faible (c'est la raison pour laquelle GCG combine les gradients avec la recherche avide). Nous pouvons donc construire une attaque simple par requête uniquement en ignorant complètement le gradient ; cela conduit à une attaque purement gourmande qui échantillonne des remplacements aléatoires de jetons et interroge la perte de la cible pour vérifier si des progrès ont été réalisés. Cependant, comme l'attaque GCG en boîte blanche est déjà assez coûteuse, le surcoût supplémentaire lié à l'absence d'informations sur le gradient peut être prohibitif.

C'est pourquoi nous introduisons une optimisation supplémentaire à GCG, qui réduit empiriquement le nombre de requêtes de modèle par un facteur de 2×. Cette optimisation peut présenter un intérêt indépendant. Notre variante d'attaque diffère de la GCG comme suit : dans la GCG originale, chaque itération d'attaque calcule la perte pour B candidats, chacun obtenu en remplaçant le jeton dans une position aléatoire du suffixe.

Ainsi, pour un suffixe de longueur l, GCG essaie en moyenne B/l jetons à chaque position. Au lieu de cela, nous concentrons notre recherche sur une seule position du suffixe adverse. Au lieu de choisir cette position au hasard comme dans AutoPrompt, nous essayons d'abord de remplacer un seul token dans chaque position, puis nous notons la position où ce remplacement a le plus réduit la perte. Nous essayons ensuite B′ remplacements supplémentaires pour cette seule position. En pratique, nous pouvons fixer B′ ≪ B sans affecter le taux de réussite de l'attaque.

Les résultats annoncés, bien qu’impressionnants, masquent des variations critiques. Par exemple, les taux d’échec élevés pour les attaques d’hameçonnage et de manipulation de code suggèrent que Gemini intègre déjà des contre-mesures partielles, non documentées dans l’étude. Par ailleurs, l’absence de tests contre des défenses actives (filtrage des prompts, détection d’anomalies) rend difficile l’évaluation de la robustesse réelle de cette attaque. Une approche plus complète aurait inclus des benchmarks contre des techniques comme le perplexity-based filtering ou l’input sanitization, couramment utilisées pour contrer les injections de prompts.

Enfin, la méthodologie repose sur des hypothèses peu réalistes, comme un accès illimité aux itérations de fine-tuning, sans considérer les contraintes pratiques (coûts computationnels, quotas d’API). Les « redémarrages » de l’algorithme, bien qu’augmentant marginalement les taux de réussite, soulèvent des questions sur leur efficacité réelle : sont-ils le fruit d’une optimisation stochastique ou simplement d’un bruit expérimental ? Une...