Riepilogo Tecnico: Needles at Scale (Aghi su Larga Scala)

Definizione del Problema

Il collo di bottiglia principale nella moderna ricerca di vulnerabilità per sistemi operativi a codice chiuso non è l'analisi delle singole funzioni, ma la selezione dei target. Un moderno' immagine Windows contiene milioni di funzioni (il "pagliaio"), ma solo una frazione minuscola è rilevante per specifiche classi di vulnerabilità. Sebbene gli strumenti di analisi (esecuzione simbolica, fuzzer, agenti LLM) si siano evoluti, essi rimangono dispendiosi in termini di risorse. Un agente LLM, ad esempio, spreca costosi contesti di finestra analizzando codice irrilevante (es. l'avvio del C-runtime) se non viene indirizzato verso la funzione corretta. Il documento sostiene che il campo debba passare dal chiedere "possiamo analizzare questa funzione?" al chiedere "quali tra i milioni di funzioni dovremmo analizzare successivamente?". Questo processo di selezione è attualmente guidato dall'intuizione, dalla reputazione e da semplici ricerche grep, mancando di un substrato di prioritizzazione sistematico e scalabile per ambiti che coprono l'intero sistema operativo.

Metodologia: Symbolicate-Enrich-Sample

Gli autori propongono Symbolicate-Enrich-Sample, una pipeline batch a tre stadi progettata per trasformare un corpus di binari Windows di produzione in una coda di ricerca classificata per priorità. La pipeline è progettata per essere a basso costo e riproducibile, operando sull'intera immagine Windows senza richiedere l'accesso al codice sorgente privato.

1. Symbolicate (Simbolizzazione)

Questa fase affronta la mancanza di simboli nei binari di produzione privi di simboli (file PE).

• Meccanismo: La pipeline analizza il record CodeView (RSDS) all'interno di ogni binario per estrarre il GUID e l'age del PDB (Program Database). Costruisce un URL canonico al server dei simboli pubblico di Microsoft, recupera il relativo PDB e lo memorizza in cache.
• Recupero: Una passata di decompilazione recupera l'insieme delle funzioni e il grafo delle chiamate inter-procedurali. La pipeline unisce poi i nomi pubblici delle funzioni dal PDB agli indirizzi delle funzioni recuperati.
• Risoluzione API: Un catalogo di circa 20.000 prototipi di API Win32/WDK viene unito alle importazioni chiamate per recuperare i prototipi dei callee per i siti di chiamata.
• Output: Un grafo delle chiamate nominato. Le funzioni prive di nomi pubblici rimangono come voci sintetiche sub_<addr> ed vengono escluse dalla fase di arricchimento successiva.

2. Enrich (Arricchimento)

Questa fase attacca caratteristiche strutturali deterministiche e label generate da LLM a ciascuna funzione nominata.

• Caratteristiche Deterministiche: Per ogni funzione, il sistema calcola:
  • Stato di esportazione.
  • Conteggio dei chiamanti/chiamati e nomi dei principali chiamanti/chiamati.
  • Presenza di API rilevanti per il rischio (sink di copia/scrittura come memcpy, RtlCopy*, allocator di pool, probe di puntatori utente).
  • Conteggio dei blocchi di base e dimensione.
  • Profondità di raggiungibilità breadth-first dai punti di ingresso (esportazioni, routine di dispatch).
• Etichettatura LLM: Un LLM a basso costo riceve in input il nome della funzione, i prototipi dei callee recuperati e le caratteristiche deterministiche. L'LLM riceve l'istruzione di ragionare partendo da queste caratteristiche (non solo dal nome) per produrre:
  • Livello di Raggiungibilità (Reachability Tier): (Remoto, locale-ipc, locale-utente, solo-admin, kernel-interno, libreria-interna).
  • Livello di Rischio: (Critico, alto, medio, basso, info).
  • Ipotesi sulla classe di Bug e Razionale.
• Ottimizzazione: Le funzioni che corrispondono a pattern noti di runtime/helper CRT vengono filtrate tramite regole (forzate a library-internal/info) per evitare chiamate superflue al modello. Il modello vede solo un riassunto strutturato compatto, mai byte decompilati grezzi.

3. Sample (Campionamento)

Questa fase converte il corpus arricchito in una coda diversificata e prioritizzata.

• Scoring (Punteggio): Un punteggio di priorità viene calcolato utilizzando una formula euristica: priority = w_reach · w_risk · w_conf · bonus. Il termine bonus premia l'evidenza deterministica (es. chiamare un sink di copia, essere esportata) e penalizza gli stub triviali.
• Strategia di Campionamento: Un campionatore di importanza pesata sulla priorità (utilizzando un algoritmo a serbatoio pesato o weighted reservoir) estrae funzioni senza sostituzione. Ciò garantisce che una sessione di ricerca copra lo spazio ad alto valore con diversità, piuttosto che restituire ripetutamente gli stessi risultati top-k.
• Flessibilità: Il sistema supporta diversi regimi: ampie scansioni "stile fuzzing" (estrazione pesata) o lavoro mirato guidato da ipotesi (filtri stretti con selezione top-N).

Risultati Chiave e Valutazione

La pipeline è stata applicata a un corpus di 5.888 binari firmati x86-64 Windows 11 (build 10.0.26100), recuperando 7.231.419 funzioni.

• Recupero Simboli: Il 76,8% delle funzioni recuperate (5.553.074) ha ricevuto nomi PDB pubblici ed è stato arricchito. Il restante 23,2% sono stati stubs non nominati esclusi dall'arricchimento.
• Selettività: Il processo di etichettatura è altamente conservativo.
  • Solo lo 0,18% delle funzioni è stato etichettato come critical.
  • Solo l'1,83% è stato etichettato come rivolto al remote (remoto).
  • La maggior parte delle funzioni è stata correttamente declassata a library-internal o info (es. meccanismi di eccezione C++, boilerplate).
• Il Imbuto (The Funnel): Sovrapponendo le etichette del modello con filtri deterministici (Rischio: alto/critico AND Raggiungibilità: remoto/locale-ipc AND Chiama un primitivo di memoria non sicura), lo spazio di ricerca viene ridotto di circa 2,5 ordini di grandezza, da 7,23 milioni di funzioni a una lista breve di circa 22.000 funzioni.
• Modalità di Fallimento: Gli autori hanno identificato due debolezze sistematiche nel livello superiore:
  1. Sovra-estensione (Over-reach): Assegnare classi di bug specifiche (es. use-after-free) a funzioni prive dei necessari vettori di caratteristiche (es. assenza di un sink di copia/scrittura).
  2. Inflazione della Raggiungibilità: Etichettare funzioni di parsing profondo come remote anche quando la profondità del grafo delle chiamate suggerisce il contrario.
     Mitigazione: Semplici guardie (es. proibire etichette concrete di classe di copia senza un corrispondente sink) possono mitigare il primo modulo di fallimento senza rieseguire il modello.

Significato e Rivendicazioni

Il documento inquadra esplicitamente il proprio contributo come un substrato di selezione, non come un rilevatore di bug. Non afferma di aver scoperto nuove vulnerabilità. Invezione, fornisce lo strato di prioritizzazione su cui un rilevatore a valle o un agente LLM dovrebbe operare.

• Scalabilità: Dimostra che la ricerca di vulnerabilità su interi sistemi operativi è fattibile alla scala di milioni di funzioni utilizzando LLM a basso costo, a condizione che l'LLM sia ancorato a caratteristiche strutturali deterministiche piuttosto che al codice grezzo.
• Spostamento Metodologico: Riformula la ricerca di vulnerabilità da un puro problema di analisi a un problema di recupero delle informazioni e classificazione dei candidati.
• Politica dei Dati: Gli autori non pubblicano il dataset derivato (annotazioni a livello di funzione) per ragioni legali (copyright dei binari Microsoft) e di preoccupazioni sul doppio uso (fornire una mappa classificata della superficie di attacco potrebbe aiutare gli attaccanti). Tuttavia, la metodologia è pienamente riproducibile utilizzando binari Windows e server dei simboli pubblicamente disponibili.

Il documento conclude che, sebbene la lista breve migliori la trattabilità del problema, la domanda centrale rimane se questa lista prioritaria migliori effettivamente la resa nella scoperta di bug reali rispetto a una ricerca non informata, una questione lasciata al lavoro futuro riguardante cicli di calibrazione e verifica con l'intervento umano.