Discussion :

[Bruno]

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

Vers septembre 2023, OpenAI a supprimé la possibilité de calculer les logprobs pour les tokens fournis dans le cadre de l'invite. Sans cela, il n'y avait pas de moyen direct de déterminer le logprob cumulatif d'une chaîne cible conditionnée par une invite. Heureusement, les fonctionnalités existantes de l'API pouvaient être combinées pour reconstruire cette valeur, bien qu'à un coût plus élevé. C'est la méthode que nous avons utilisée pour les résultats de la chaîne de caractères nuisibles de l'OpenAI. Plus tard, en mars 2024, OpenAI a mis à jour son API pour que le paramètre logit_bias n'affecte pas les jetons renvoyés par top_logprobs. En mai 2024, il est toujours possible de déduire les logprobs en utilisant la procédure de recherche binaire de, bien que l'attaque résultante soit significativement plus coûteuse.

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
input : vocabulary V={vi}i=1n, sequence length m, loss ℓ:Vm→ℝ, proxy loss ℓp:Vm→ℝ, iteration count T, proxy batch size bp, query batch size bq, buffer size B
buffer←B uniform samples from Vm
for i∈[T] do
       for i∈[bq] do
             j∼Unif⁡([m]),t∼Unif⁡(V)
             batchi←arg⁡minb∈buffer⁡ℓ⁢(b)
             (batchi)j←t
             plossi←ℓp⁢(batchi)
       end for
      for i∈Top−bq⁡(ploss) do
             loss←ℓ⁢(batchi)
             bworst←arg⁡maxb∈buffer⁡ℓ⁢(b)
             if loss≤ℓ⁢(bworst) then
                   remove bworst from buffer
                   add batchi to buffer
 
             end if
 
       end for
 
end for
return arg⁡minb∈buffer⁡ℓ⁢(b)

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 analyse plus fine des hyperparamètres et des coûts associés aurait renforcé la crédibilité des conclusions.

En l’état, cette recherche ouvre des perspectives intéressantes mais reste incomplète. Une évaluation plus exhaustive des vulnérabilités structurelles des LLM, incluant des comparaisons inter-modèles et des tests contre des défenses avancées, serait nécessaire pour en confirmer la portée. Par ailleurs, l’absence de discussion sur des vecteurs d’attaque complémentaires (comme le data poisoning ou les attaques par inférence) limite sa contribution à une vision fragmentaire des risques liés aux LLM.

Analyse critique des vulnérabilités des LLM et de l'attaque Fun-Tuning

L'émergence de la technique Fun-Tuning contre Gemini marque effectivement un tournant dans le domaine de la sécurité des LLM, transformant ce qui était traditionnellement un processus artisanal en une méthode systématique et algorithmique. Cette évolution soulève plusieurs questions fondamentales sur l'équilibre entre accessibilité et sécurité dans les modèles propriétaires.

Le principal intérêt de cette attaque réside dans son exploitation ingénieuse des API de fine-tuning, révélant une faille paradoxale : les mécanismes conçus pour améliorer la spécialisation des modèles deviennent des vecteurs d'attaque. L'utilisation des valeurs de perte comme signal d'optimisation est particulièrement astucieuse, car elle contourne l'opacité des modèles fermés.

Cependant, cette approche présente des limites importantes. D'une part, son efficacité semble variable selon les types d'attaques (moins performante pour le phishing ou la manipulation de code), suggérant que Gemini intègre déjà certaines protections non documentées. D'autre part, le temps de calcul requis (60 heures) et la nécessité d'accès aux API de fine-tuning en réduisent la dangerosité immédiate. Sur le plan technique, plusieurs aspects méritent un examen plus approfondi :

1. La transférabilité supposée entre différentes versions de Gemini n'est pas suffisamment étayée par une analyse des similarités architecturales sous-jacentes ;
2. L'étude ne compare pas cette méthode avec des attaques existantes sur d'autres LLM (comme GPT-4 ou Claude), ce qui limite notre capacité à évaluer si cette vulnérabilité est spécifique à Gemini ou plus générale ;
3. Aucune contre-mesure avancée (comme le filtrage par perplexité ou l'analyse des embeddings) n'a été testée contre cette attaque.

L'affirmation selon laquelle cette technique change la donne" semble quelque peu prématurée. Si elle démontre effectivement une nouvelle classe de vulnérabilités, son impact pratique reste à nuancer :

• Les cas d'usage les plus critiques (sécurité des données, intégrité du code) résistent partiellement ;
• Les coûts computationnels et la nécessité d'accès API la rendent difficile à industrialiser ;
• Les fournisseurs de LLM pourraient relativement facilement restreindre l'accès aux valeurs de perte ou implémenter des mécanismes de détection.

En conclusion, bien que Fun-Tuning représente une avancée conceptuelle importante dans l'étude des vulnérabilités des LLM, son importance pratique ne doit pas être surestimée. Cette recherche met surtout en lumière le dilemme fondamental auquel font face les fournisseurs de modèles : comment concilier ouverture (nécessaire au fine-tuning et à la spécialisation) et sécurité. La solution résidera probablement dans des architectures plus robustes plutôt que dans la restriction pure des fonctionnalités, sous peine de limiter l'utilité même des LLM.

Source : Research paper

Et vous ?

Quel est votre avis sur le sujet ?

Le dilemme sécurité/utilité est-il inhérent à tous les LLM ou amplifié par les choix d'implémentation de Google ? Les modèles ouverts seraient-ils plus résilients ?

Voir aussi :

Gemini 1.5 pro en passe de changer le développement de logiciels ? Cette IA peut comprendre une base de code entière et proposer des correctifs : vers une mise au rebut des développeurs humains ?

Google donne plus de détails sur Gemma, une famille de modèles d'IA ouverts qui a servi à créer Gemini, avec une nouvelle boîte à outils d'IA générative pour l'adapter à vos besoins

Google DeepMind a lancé Gemini 2.5 Pro, un modèle d'IA qui raisonne avant de répondre, affirmant qu'il est le meilleur sur plusieurs critères de référence en matière de raisonnement et de codage