Résumé technique : POC-GYM : Vers une génération plus fiable d'exploits de preuve de concept assistée par les LLM

Énoncé du problème

La génération d'exploits de preuve de concept (PoC) est cruciale pour valider les vulnérabilités, faciliter le développement de correctifs et servir de tests de régression. Cependant, une fraction significative des vulnérabilités divulguées publiquement ne dispose pas de PoC disponibles. Bien que les modèles de langage (LLM) soient de plus en plus utilisés pour automatiser la détection de vulnérabilités et la génération d'exploits, les approches existantes souffrent souvent de problèmes de fiabilité.

Les méthodes actuelles assistées par LLM génèrent généralement des PoC à partir de descriptions de vulnérabilités et les valident en utilisant des signaux superficiels, tels que des marqueurs imprimés, des fichiers générés ou des effets de bord à l'exécution. Le problème central identifié par les auteurs est que ces signaux peuvent être satisfaits par des chemins de code « faux positifs » qui ne déclenchent pas réellement la vulnérabilité sous-jacente. Par conséquent, un PoC peut sembler réussi lors de vérifications automatisées à l'exécution tout en échouant à atteindre l'emplacement réel du code vulnérable (la vérité terrain). Il existe un besoin d'un pipeline de génération plus fiable capable de distinguer entre un succès superficiel et une exploitation véritable.

Méthodologie : Cadre PoC-Gym

Les auteurs proposent PoC-Gym, un pipeline hybride conçu pour générer des exploits PoC en Java en combinant des traces de flux de données issues de l'analyse statique de sécurité (SAST) avec le raisonnement des LLM. Le cadre fonctionne en trois étapes itératives :

1. Construction de l'invite :

   • Contexte spécifique à la vulnérabilité : Le système utilise un LLM pour générer des « directives spécifiques au CVE », définissant un objectif d'exploit concret et une vérification de validation programmatique basée sur les descriptions du CVE et de l'Enumeration des Faiblesses Courantes (CWE).
   • Contexte de trace : Pour fournir des chemins de programme concrets, PoC-Gym intègre des traces de flux de données source-vers-sink statiques extraites à l'aide de CodeQL et du framework IRIS. Ces traces sont classées par un assistant de triage LLM pour sélectionner les chemins les plus pertinents avant d'être formatées et insérées dans l'invite.
   • Contraintes du référentiel : L'invite inclut des métadonnées sur le référentiel vulnérable (URL, commit, scripts de construction) et des contraintes strictes sur l'utilisation des API (par exemple, éviter la réflexion, limiter les dépendances) pour garantir que le code généré est exécutable.

2. Génération du PoC :

   • Un agent LLM (par exemple, Claude Sonnet 4, GPT-5) reçoit l'invite structurée et génère un seul fichier source Java (PoCTest.java).
   • L'agent est contraint de créer une classe publique avec une méthode main qui déclenche la vulnérabilité et imprime un marqueur de succès spécifique ([VULN]).

3. Validation du PoC :

   • Validation à l'exécution : Le candidat PoC est compilé et exécuté sur le projet vulnérable en utilisant l'instrumentation AspectJ. Un candidat est jugé « valide à l'exécution » uniquement s'il :
     1. Se termine avec succès (code de sortie 0).
     2. Imprime le marqueur [VULN].
     3. Atteint l'emplacement sink spécifique défini dans la trace statique (Accessibilité du Sink).
   • Rétroaction itérative : Si la validation échoue, un résumé d'échec (incluant la sortie et la couverture de la trace) est ajouté à l'invite pour l'itération suivante.
   • Validation a posteriori : Crucialement, les auteurs introduisent une étape de validation distincte contre les emplacements vulnérables « vérité terrain » fournis par le benchmark CWE-Bench-Java. Cette étape vérifie si l'exécution a réellement atteint la plage de fichier et de ligne spécifique identifiée dans le correctif, distinguant ainsi la véritable exploitation de la simulation.

Contributions clés

• Pipeline hybride : L'intégration de traces de flux de données dérivées de l'analyse statique avec la génération par LLM et des vérifications dynamiques d'accessibilité du sink pour guider la génération d'exploits.
• Mécanisme de double validation : La distinction entre « valide à l'exécution » (satisfaisant les critères de la boucle de génération) et « valide a posteriori » (atteignant l'emlocation vulnérable vérité terrain), mettant en évidence la surestimation du succès dans les méthodes existantes.
• Analyse complète des échecs : Une analyse manuelle approfondie des PoC ayant passé la validation à l'exécution mais échoué aux vérifications a posteriori, catégorisant les modes d'échec tels que les « erreurs sans rapport » (traces/descriptions incorrectes), le « codage en dur », la « simulation » (réimplémentant la logique de la vulnérabilité au lieu de l'invoker) et la « mauvaise validation » (signaux de succès peu fiables).

Résultats expérimentaux

Les auteurs ont évalué PoC-Gym sur 20 CVE Java réels issus de CWE-Bench-Java en utilisant trois configurations LLM différentes.

• Validité à l'exécution vs Validité a posteriori : Sur 338 exécutions, PoC-Gym a généré 116 candidats valides à l'exécution (34,3 %). Cependant, après validation a posteriori contre les emplacements vérité terrain, seuls 65 candidats (19,2 %) ont été confirmés valides. Cela indique que 44 % des candidats apparaissant réussis lors des vérifications à l'exécution étaient en réalité de faux positifs n'atteignant pas le sink réel de la vulnérabilité.
• Impact de l'orientation par les traces : Les expériences sans informations de traces ont atteint un taux de réussite initial à l'exécution plus élevé (86,7 %) mais une validité a posteriori beaucoup plus faible (36,7 %). En revanche, le paramètre multi-traces avait un taux de réussite initial plus faible (23,0 %) mais une baisse moindre de la validité a posteriori (15,5 %), suggérant que l'orientation par les traces aide à filtrer les solutions invalides qui ne correspondent pas aux chemins vulnérables réels.
• Comparaison avec FaultLine : Sur les 14 CVEs chevauchant avec le système FaultLine, la configuration PoC-Gym la plus performante (Claude Sonnet 4 avec traces) a obtenu 8/14 résultats valides a posteriori, contre 5/14 pour FaultLine selon ses critères d'évaluation d'origine.

Importance et affirmations

L'article affirme que, bien que les LLM montrent des promesses dans la génération de stratégies d'exploitation, ils ne peuvent pas être considérés comme un remplacement complet des techniques de génération de tests déterministes. Les auteurs soutiennent que :

1. La fiabilité nécessite une validation vérité terrain : Les signaux à l'exécution seuls surestiment considérablement la correction des exploits ; une validation a posteriori contre des emplacements vulnérables connus est nécessaire pour évaluer l'efficacité réelle.
2. Le contexte de trace réduit les faux positifs : Bien que les traces statiques n'éliminent pas tous les échecs, elles réduisent significativement la proportion de solutions invalides satisfaisant des signaux de succès superficiels.
3. Les motifs d'échec sont systématiques : De nombreux échecs proviennent de motifs spécifiques et récurrents (par exemple, le LLM simulant la vulnérabilité au lieu de la déclencher, ou utilisant des traces sans rapport). Comprendre ces motifs est essentiel pour améliorer la conception des systèmes futurs.

Les auteurs concluent que les progrès futurs dans la génération de PoC assistée par LLM dépendent non seulement de l'amélioration de la qualité de génération, mais aussi du développement de mécanismes de validation plus robustes et de l'utilisation de l'analyse des échecs pour guider la combinaison de la créativité des LLM avec des vérifications basées sur des spécifications.