Riepilogo Tecnico: POC-GYM: Verso una Generazione di Sfruttamenti Proof-of-Concept Assistita da LLM Più Affidabile

Enunciato del Problema

La generazione di exploit Proof-of-Concept (PoC) è fondamentale per convalidare le vulnerabilità, supportare lo sviluppo di patch e fungere da test di regressione. Tuttavia, una frazione significativa delle vulnerabilità divulgate pubblicamente non dispone di PoC disponibili. Sebbene i Modelli Linguistici su Larga Scala (LLM) siano stati sempre più applicati per automatizzare il rilevamento delle vulnerabilità e la generazione di exploit, gli approcci esistenti soffrono spesso di problemi di affidabilità.

I metodi attuali assistiti da LLM generano tipicamente PoC basandosi sulle descrizioni delle vulnerabilità e li convalidano utilizzando segnali superficiali, come marcatori stampati, file generati o effetti collaterali a runtime. Il problema centrale identificato dagli autori è che questi segnali possono essere soddisfatti da percorsi di codice "falsi positivi" che non attivano effettivamente la vulnerabilità sottostante. Di conseguenza, un PoC può apparire riuscito sotto i controlli automatici a runtime pur non raggiungendo la reale posizione del codice vulnerabile (la verità di base). È necessaria una pipeline di generazione più affidabile che distingua tra il successo superficiale e lo sfruttamento genuino.

Metodologia: Framework PoC-Gym

Gli autori propongono PoC-Gym, una pipeline ibrida progettata per generare exploit PoC in Java combinando tracciati di flusso di dati derivati dal Static Application Security Testing (SAST) con il ragionamento degli LLM. Il framework opera attraverso tre fasi iterative:

1. Costruzione del Prompt:

   • Contesto Specifico per la Vulnerabilità: Il sistema utilizza un LLM per generare una "guida specifica per CVE" esplicita, definendo un obiettivo di sfruttamento concreto e un controllo di validazione programmatico basato sulle descrizioni del CVE e della Common Weakness Enumeration (CWE).
   • Contesto del Tracciato: Per fornire percorsi di programma concreti, PoC-Gym integra tracciati di flusso di dati statici da sorgente a destinazione estratti utilizzando CodeQL e il framework IRIS. Questi tracciati sono classificati da un assistente di triage LLM per selezionare i percorsi più rilevanti prima di essere formattati e inseriti nel prompt.
   • Vincoli del Repository: Il prompt include metadati sul repository vulnerabile (URL, commit, script di build) e vincoli rigorosi sull'uso delle API (ad esempio, evitare la riflessione, limitare le dipendenze) per garantire che il codice generato sia eseguibile.

2. Generazione del PoC:

   • Un agente LLM (ad esempio, Claude Sonnet 4, GPT-5) riceve il prompt strutturato e genera un singolo file sorgente Java (PoCTest.java).
   • L'agente è vincolato a creare una classe pubblica con un metodo main che attiva la vulnerabilità e stampa un marcatore di successo specifico ([VULN]).

3. Validazione del PoC:

   • Validazione a Runtime: Il PoC candidato viene compilato ed eseguito sul progetto vulnerabile utilizzando l'istrumentazione AspectJ. Un candidato è considerato "valido a runtime" solo se:
     1. Termina con successo (codice di uscita 0).
     2. Stampa il marcatore [VULN].
     3. Raggiunge la specifica posizione di destinazione definita nel tracciato statico (Raggiungibilità della Destinazione).
   • Feedback Iterativo: Se la validazione fallisce, un riepilogo degli errori (inclusi output e copertura del tracciato) viene aggiunto al prompt per la successiva iterazione.
   • Validazione Post-Hoc: Crucialmente, gli autori introducono un passaggio di validazione separato contro le posizioni vulnerabili "verità di base" fornite dal benchmark CWE-Bench-Java. Questo passaggio verifica se l'esecuzione ha effettivamente raggiunto il file e l'intervallo di righe specifici identificati nella patch, distinguendo lo sfruttamento vero dalla simulazione.

Contributi Chiave

• Pipeline Ibrida: L'integrazione di tracciati di flusso di dati derivati dall'analisi statica con la generazione LLM e controlli dinamici di raggiungibilità della destinazione per guidare la generazione degli exploit.
• Meccanismo di Dual-Validazione: La distinzione tra "valido a runtime" (che soddisfa i criteri del ciclo di generazione) e "valido post-hoc" (che raggiunge la posizione vulnerabile verità di base), evidenziando la sovrastima del successo nei metodi esistenti.
• Analisi Completa degli Errori: Un'analisi manuale approfondita dei PoC che hanno superato la validazione a runtime ma fallito i controlli post-hoc, classificando le modalità di fallimento come "errori non correlati" (tracciati/descrizioni errati), "hardcoding", "simulazione" (riimplementazione della logica della vulnerabilità invece della sua attivazione) e "validazione scadente" (segnali di successo inaffidabili).

Risultati Sperimentali

Gli autori hanno valutato PoC-Gym su 20 CVE Java reali tratti da CWE-Bench-Java utilizzando tre diverse configurazioni LLM.

• Validità a Runtime vs. Post-Hoc: Su 338 esecuzioni, PoC-Gym ha generato 116 candidati validi a runtime (34,3%). Tuttavia, dopo la validazione post-hoc contro le posizioni verità di base, solo 65 candidati (19,2%) sono stati confermati validi. Ciò indica che il 44% dei candidati apparsi riusciti sotto i controlli a runtime erano in realtà falsi positivi che non raggiungevano il vero sink della vulnerabilità.
• Impatto della Guida dei Tracciati: Gli esperimenti senza informazioni sui tracciati hanno raggiunto un tasso di successo iniziale a runtime più alto (86,7%) ma una validità post-hoc molto più bassa (36,7%). Al contrario, l'impostazione multi-tracciato ha avuto un tasso di successo iniziale più basso (23,0%) ma un calo minore nella validità post-hoc (15,5%), suggerendo che la guida dei tracciati aiuta a filtrare soluzioni non valide che non corrispondono a percorsi vulnerabili reali.
• Confronto con FaultLine: Sulle 14 CVE sovrapposte al sistema FaultLine, la configurazione più forte di PoC-Gym (Claude Sonnet 4 con tracciati) ha ottenuto 8/14 risultati validi post-hoc, rispetto a 5/14 per FaultLine secondo i suoi criteri di valutazione originali.

Significato e Affermazioni

Il documento afferma che, sebbene gli LLM mostrino promesse nella generazione di strategie di sfruttamento, non possono essere trattati come un sostituto completo delle tecniche deterministiche di generazione di test. Gli autori sostengono che:

1. L'affidabilità richiede una validazione verità di base: I segnali a runtime da soli sovrastimano sostanzialmente la correttezza degli exploit; è necessaria una validazione post-hoc contro posizioni vulnerabili note per valutare l'efficacia reale.
2. Il contesto dei tracciati riduce i falsi positivi: Sebbene i tracciati statici non eliminino tutti gli errori, riducono significativamente la proporzione di soluzioni non valide che soddisfano segnali di successo superficiali.
3. I modelli di fallimento sono sistematici: Molti errori derivano da pattern specifici e ricorrenti (ad esempio, l'LLM che simula la vulnerabilità invece di attivarla, o l'uso di tracciati non correlati). Comprendere questi pattern è essenziale per migliorare la progettazione dei sistemi futuri.

Gli autori concludono che i progressi futuri nella generazione assistita da LLM di PoC dipendono non solo dal miglioramento della qualità della generazione, ma anche dallo sviluppo di meccanismi di validazione più robusti e dall'uso dell'analisi degli errori per guidare la combinazione della creatività degli LLM con controlli basati sulle specifiche.