← Derniers articles
💻 computer science

From Documentation to Zero-day Vulnerabilities: LLM-Driven Fuzzing of JavaScript Engines in PDF Readers

Cet article présente PDFuzzer, un nouveau fuzzer piloté par les LLM qui exploite les grands modèles de langage pour inférer les relations entre les API et générer des séquences d'appels complexes, améliorant ainsi considérablement la couverture de code et découvrant 31 vulnérabilités zero-day dans les lecteurs PDF grand public par rapport aux outils de pointe existants.

Auteurs originaux : Suyue Guo, Stijn Pletinckx, Tianle Yu, Yigitcan Kaya, Saad Ullah, Wenbo Guo, Christopher Kruegel, Giovanni Vigna

Publié 2026-08-20
📖 8 min de lecture🧠 Analyse approfondie

Auteurs originaux : Suyue Guo, Stijn Pletinckx, Tianle Yu, Yigitcan Kaya, Saad Ullah, Wenbo Guo, Christopher Kruegel, Giovanni Vigna

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez un document numérique qui fait bien plus que de simplement rester sur un écran ; il peut réfléchir, calculer et réagir. C'est la promesse du format de document portable, ou PDF, lorsqu'il est équipé d'un moteur de JavaScript, un programme informatique intégré. Tout comme un livre physique pourrait posséder un compartiment caché qui ne s'ouvre que lorsqu'une page spécifique est tournée, un PDF peut contenir du code qui s'exécute à l'intérieur de l'application de lecture, permettant des formulaires interactifs, la vérification orthographique et des menus dynamiques. Cependant, cette puissance comporte un risque. Si un pirate parvient à tromper ce moteur pour lui faire commettre une erreur, il peut potentiellement prendre le contrôle de l'ordinateur qui lit le fichier, voler des données ou installer des logiciels malveillants. Pendant des années, les chercheurs en sécurité ont tenté de trouver ces pièges cachés en lançant des variations aléatoires de documents vers les lecteurs PDF, espérant voir le programme planter. Mais cette méthode est souvent comparable à un lancer de fléchettes dans l'obscurité ; elle manque les séquences d'actions complexes et spécifiques requises pour déclencher les failles les plus dangereuses.

Une équipe de chercheurs de l'Université de Californie, à Santa Barbara, a développé une nouvelle approche à ce problème, passant du tâtonnement aveugle au raisonnement intelligent. Ils ont créé un outil appelé PDFuzzer, qui agit moins comme un lanceur de fléchettes et plus comme un étudiant ayant étudié minutieusement le manuel d'instructions avant de tenter une tâche. Au lieu de s'appuyer sur des commandes simples et isolées, ce système apprend comment différentes parties du langage de programmation du moteur PDF dépendent les unes des autres. Il comprend que pour effectuer une action spécifique, un utilisateur peut devoir établir une condition au préalable, ou que deux commandes différentes doivent utiliser exactement le même nom pour fonctionner ensemble. En apprenant à un ordinateur à lire et à comprendre la documentation complexe et écrite de ces moteurs de logiciels, les chercheurs ont pu générer des cas de test hautement sophistiqués que les outils précédents ne pouvaient tout simplement pas concevoir.

Le cœur de cette nouvelle méthode réside dans la manière dont elle gère les « règles » du logiciel. Par le passé, les outils de test automatisés éprouvaient souvent des difficultés car ils ne comprenaient que des connexions basiques, telles qu'une commande transmettant un résultat à la suivante comme un témoin dans une course de relais. Ils manquaient des relations plus subtiles, comme le fait que deux commandes doivent utiliser la même valeur spécifique pour interagir correctement, ou qu'une commande établisse un état caché sur lequel une commande ultérieure compterait. PDFuzzer utilise un modèle de langage étendu, un type d'intelligence artificielle entraîné sur de vastes quantités de texte, pour lire les manuels officiels et les traces techniques du logiciel. Il construit ensuite une carte détaillée de la manière dont chaque fonction se rapporte à toutes les autres fonctions. Il traduit ces descriptions écrites en règles logiques strictes, garantissant que lors de la génération d'un test, les paramètres correspondent parfaitement. Par exemple, si une commande nécessite l'utilisation d'un nom spécifique, le système s'assure que le même nom est utilisé dans la commande suivante qui en a besoin, plutôt que de deviner de manière aléatoire.

Pour tester leur création, les chercheurs ont appliqué PDFuzzer à trois des lecteurs PDF les plus populaires utilisés dans le monde entier : Adobe Acrobat Reader, Foxit PDF Reader et PDF-XChange Editor. Ils ont fait tourner leur outil pendant des semaines, comparant ses performances aux meilleures méthodes existantes utilisées aujourd'hui par les experts en sécurité. Les résultats furent frappants. Alors que les anciens outils n'exploraient qu'une fraction de la logique interne du logiciel, PDFuzzer est allé nettement plus loin, couvrant jusqu'à 48 % de code supplémentaire. Plus important encore, cette exploration plus profonde a conduit à la découverte de 31 vulnérabilités de sécurité auparavant inconnues, appelées vulnérabilités « zero-day ». Il ne s'agissait pas de glitches mineurs ; beaucoup étaient des problèmes sérieux qui pourraient permettre à un attaquant d'exécuter du code arbitraire, prenant essentiellement le contrôle total de l'ordinateur de la victime, ou de divulguer des informations sensibles. En revanche, les autres outils n'ont trouvé au plus que six vulnérabilités de ce type durant la même période.

Les chercheurs ne se sont pas contentés de trouver les bugs ; ils ont travaillé directement avec les éditeurs de logiciels pour les corriger. À travers un processus coordonné, ils ont divulgué les détails des 31 vulnérabilités aux entreprises responsables des lecteurs PDF. L'industrie a réagi rapidement, 26 des problèmes ayant été confirmés et corrigés, et dix ayant reçu des identifiants de sécurité officiels pour avertir les utilisateurs. Les chercheurs ont également reçu des récompenses financières, connues sous le nom de « bug bounties », totalisant 2 450 $ pour leur travail. Ce résultat souligne la valeur pratique de leur approche : en automatisant la tâche difficile de compréhension des interactions complexes de logiciels, ils ont pu trouver et corriger des dangers que les experts humains et les anciens outils automatisés avaient manqués.

Un élément clé du succès fut la manière dont l'outil a traité la vaste quantité d'informations contenues dans les manuels du logiciel. La documentation de ces moteurs peut faire des centaines de pages, remplie de détails techniques difficiles à analyser automatiquement pour un ordinateur. Les chercheurs ont constaté que demander simplement à une intelligence artificielle de générer des cas de test à partir de zéro était lent et produisait souvent des absurdités. Au lieu de cela, ils ont utilisé l'IA pour agir comme un traducteur, convertissant le langage naturel des manuels en règles précises et lisibles par machine. Ils ont décomposé le processus en étapes : d'abord, l'extraction de la structure de base des commandes ; ensuite, l'inférence des détails cachés pour les commandes qui n'étaient pas entièrement documentées ; et enfin, l'utilisation d'un solveur mathématique pour s'assurer que les cas de test générés satisfaisaient toutes les contraintes logiques. Cette approche hybride, combinant la puissance de raisonnement d'une intelligence artificielle avec la précision de la logique mathématique, s'est avérée bien plus efficace et performante que de s'appuyer sur l'IA seule.

L'étude a également révélé que les vulnérabilités les plus dangereuses nécessitaient souvent une séquence d'événements spécifique que les outils précédents ne pouvaient pas reproduire. Par exemple, une faille impliquait une situation où un élément de l'interface utilisateur était créé puis immédiatement supprimé, mais où une commande ultérieure tentait de l'utiliser à nouveau. Pour déclencher cela, le cas de test devait créer l'élément, l'utiliser, le supprimer, puis tenter d'y accéder à nouveau, tout en s'assurant que les noms et les valeurs utilisés à chaque étape étaient identiques. Les anciens outils, qui traitaient chaque commande comme un événement isolé, ne pouvaient pas générer cette chaîne d'événements spécifique. PDFuzzer, en comprenant la relation entre les commandes, pouvait construire la séquence exacte nécessaire pour exposer la faille. Cette capacité à modéliser des dépendances complexes fut le facteur décisif dans la découverte de la majorité des nouvelles vulnérabilités.

Au-delà du succès immédiat avec les lecteurs PDF, les chercheurs suggèrent que leur méthode pourrait être appliquée à d'autres domaines de la sécurité logicielle où une documentation détaillée existe. Ils ont testé leur pipeline sur le langage de programmation utilisé pour les macros de Microsoft Word, un environnement différent mais similaire en complexité, et ont constaté que les mêmes types de relations et de dépendances existaient là aussi. Cela indique que le défi de comprendre comment les composants logiciels interagissent n'est pas propre aux lecteurs PDF, mais est un problème répandu dans l'informatique moderne. La capacité de transformer automatiquement les manuels écrits en règles de test rigoureuses offre une nouvelle voie pour sécuriser les logiciels qui alimentent notre vie quotidienne.

En fin de compte, ce travail démontre que l'avenir de la sécurité logicielle pourrait résider dans l'apprentissage aux ordinateurs de lire et de comprendre les instructions que nous leur écrivons. En comblant le fossé entre la documentation écrite par l'homme et les tests générés par machine, les chercheurs ont montré que nous pouvons trouver et corriger des failles dangereuses plus rapidement et plus minutieusement qu'auparavant. Les 31 vulnérabilités qu'ils ont découvertes rappellent à quel point une complexité immense reste cachée dans les logiciels que nous utilisons chaque jour, et à quel point nous pouvons être plus en sécurité lorsque nous disposons d'outils assez intelligents pour trouver les fissures avant les acteurs malveillants. Le processus n'était pas une question de magie ou de chance, mais de construction d'un système capable de réfléchir à la logique du logiciel, garantissant que chaque cas de test soit une tentative significative de briser le système, plutôt qu'une supposition aléatoire.

Noyé(e) sous les articles dans votre domaine ?

Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.

Essayer Digest →