Anthropic affirme qu’un modèle Claude non commercialisé est allé au-delà de la détection des vulnérabilités logicielles, en combinant des failles de sécurité pour créer cinq chaînes d’exploitation fonctionnelles dans plusieurs navigateurs et systèmes d’exploitation.
Dans une étude publiée le 27 octobre, l’entreprise décrit des démonstrations impliquant Chrome, Safari, Android, Windows et Linux. Une preuve de concept visant Chrome serait sortie du bac à sable du navigateur après l’ouverture d’une page web malveillante, tandis qu’une démonstration sous Linux aurait permis d’exécuter des commandes avec des privilèges root.
Les tests ont été réalisés dans des environnements contrôlés et ne correspondent pas à des attaques documentées dans le monde réel. Ils soulèvent toutefois une question urgente pour les équipes de sécurité : les organisations peuvent-elles identifier et corriger les vulnérabilités assez rapidement à mesure que les systèmes d’IA deviennent plus capables de développer des exploits complexes ?
Claude est passé de la détection de bugs à la création de chaînes d’exploitation
Une chaîne d’exploitation combine des failles pour contourner plusieurs protections. Anthropic précise que Claude a analysé du code, rétro-ingénieré des logiciels et testé des exploits après avoir reçu des instructions.
Dans Chrome, le modèle aurait relié quatre vulnérabilités : une corruption de mémoire dans V8, suivie de failles permettant de contourner les protections mémoire et le bac à sable du navigateur. Anthropic indique qu’une page web malveillante a déclenché une preuve de concept qui a lancé la Calculatrice de macOS sans autre interaction.
Anthropic a également indiqué que ses recherches plus larges sur Chrome avaient produit 62 CVE, dont 13 sorties du bac à sable, les correctifs ayant été intégrés à Chrome 156. La chaîne de quatre vulnérabilités constituait une démonstration parmi d’autres dans le cadre de cette étude plus vaste.
Cinq démonstrations ont franchi différentes frontières de sécurité
Les cinq chaînes d’exploitation ciblaient différentes faiblesses de sécurité, avec des conditions d’accès et des conséquences variables. Certaines commençaient par une page web malveillante, tandis que d’autres nécessitaient un accès physique ou un service réseau particulier.
Plateforme | Condition initiale | Impact signalé | Correctif signalé |
| Chrome | Page web malveillante | Exécution de code en dehors du bac à sable | Chrome 156 |
| Safari | Page web malveillante | Accès à des données intersites | Correctif Apple disponible |
| Android | Accès USB à un Pixel 9 verrouillé | Photos extraites | Correctif déployé par Google |
| Windows | Service HTTP/3 exposé | Crashes à distance | Correctif Microsoft déployé |
| Linux | Écouteur Multipath TCP | Commandes avec privilèges root | Correctif du noyau intégré en amont |
Selon Anthropic, la chaîne visant Safari a contourné la politique de même origine sans exécution de code arbitraire, tandis que la démonstration sous Windows a provoqué des plantages système à distance. La preuve de concept sous Linux a nécessité 48 minutes pour révéler une adresse du noyau, puis cinq minutes supplémentaires pour exécuter une commande root.
Ce qu’a constaté eWeek : les chaînes d’exploitation présentent des risques inégaux
Ces résultats révèlent les différences entre des preuves de concept fonctionnelles et des menaces concrètes. Les conditions d’accès, la disponibilité des correctifs et la vérification indépendante influencent la manière dont les équipes de sécurité doivent interpréter ces résultats.
L’exposition compte davantage que le nombre de chaînes d’exploitation
Les cinq démonstrations ne représentent pas cinq menaces d’urgence équivalente.
Un exploit de navigateur déclenché par une page web malveillante présente un scénario d’exposition différent d’une attaque nécessitant un accès physique à un smartphone verrouillé. De même, les vulnérabilités réseau dépendent de l’activation et de l’accessibilité des services concernés.
Pour les équipes de sécurité, cette distinction est importante lors de la hiérarchisation des mesures correctives. Une vulnérabilité touchant un service de production exposé peut nécessiter une intervention plus immédiate qu’une vulnérabilité exigeant une configuration inhabituelle ou un accès direct à l’appareil.
Ces démonstrations montrent pourquoi la possibilité d’exploitation, les conditions d’accès et la disponibilité des correctifs doivent être évaluées ensemble, plutôt que de considérer toute preuve de concept fonctionnelle comme une menace équivalente.
Les correctifs des éditeurs ne prouvent pas l’autonomie de Claude
Selon The Hacker News, Google et Apple ont reconnu que les chercheurs d’Anthropic avaient utilisé Claude pour contribuer à la découverte de certaines vulnérabilités.
Cependant, on ignore toujours quelle part du travail Claude a accomplie seul et quelle part a nécessité l’aide d’humains. Anthropic n’a pas révélé le modèle exact utilisé lors des tests, et les sources consultées n’ont pas identifié d’avis public de Google confirmant le correctif Android.
Les vulnérabilités découvertes doivent être interprétées avec prudence
The Hacker News et Mallory ont fourni des détails supplémentaires sur les vulnérabilités Windows et Linux. Les risques réels dépendent des logiciels concernés, des configurations système et des conditions nécessaires à l’exploitation. Les équipes de sécurité devraient consulter les avis des éditeurs pour confirmer leur exposition et les correctifs disponibles.
Les tests démontrent le développement d’exploits assisté par l’IA, mais pas l’existence d’attaques confirmées dans le monde réel utilisant ces chaînes d’exploitation, ni d’une exploitation entièrement autonome.
Les équipes de sécurité doivent traduire les résultats en correctifs vérifiés
Les démonstrations d’Anthropic impliquaient différents risques de sécurité ; la réponse appropriée dépend donc des systèmes concernés. Les utilisateurs, les équipes informatiques et les développeurs devraient se concentrer sur les vulnérabilités qui touchent les appareils, services ou logiciels qu’ils utilisent et administrent.
- Utilisateurs de navigateurs et de mobiles : installez les mises à jour disponibles pour les navigateurs et les appareils, et protégez les téléphones contre les accès physiques non autorisés. Le test Android nécessitait une connexion USB.
- Équipes informatiques et de sécurité : vérifiez les services HTTP/3 et Multipath TCP exposés, contrôlez les correctifs déployés et comparez les configurations concernées aux avis des éditeurs.
- Développeurs : analysez les modifications de code proposées, validez les failles signalées par l’IA et testez les correctifs avant la mise en production, plutôt que de supposer que chaque découverte correspond à un exploit fonctionnel.
« Corriger le retard existant ne résout que la moitié du problème », a écrit Anthropic, en recommandant d’effectuer des analyses de sécurité lorsque les développeurs proposent des modifications de code.
Pour les organisations, la priorité immédiate consiste à vérifier les configurations concernées, à déployer les correctifs disponibles et à tester les nouveaux codes pour détecter les faiblesses de sécurité avant leur mise en production.
L’implication plus large est que la découverte de vulnérabilités individuelles n’est peut-être plus la partie la plus difficile de l’exploitation. À mesure que les outils d’IA deviennent plus capables de combiner les failles, les équipes de sécurité devront identifier les combinaisons dangereuses avant que des attaquants ne puissent les transformer en chaînes d’exploitation fonctionnelles.
Vous souhaitez obtenir de meilleurs résultats avec des outils d’IA comme Claude ? Suivez notre cours gratuit de six minutes Comment parler à l’IA pour apprendre des méthodes simples afin de rédiger des prompts plus clairs et de travailler plus efficacement avec l’IA. Les lecteurs d’eWeek bénéficient également de sept jours d’accès gratuit aux autres cours d’IA de The Neuron Academy. Découvrez toutes les leçons ici →