Directed Symbolic Execution for Path Feasibility Analysis]{Directed Symbolic Execution for Path Feasibility Analysis in Software Security Testing
Questo articolo presenta un metodo di esecuzione simbolica diretta che migliora l'analisi statica della sicurezza verificando efficientemente la fattibilità dei percorsi interprocedurali attraverso la simbolizzazione automatizzata e i limiti di iterazione dei cicli, migliorando così significativamente la precisione pur preservando il richiamo su benchmark del mondo reale.
Articolo originale sotto licenza CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo
La sicurezza del software è una battaglia costante contro i difetti nascosti, molto simile a un urbanista che cerca di garantire che ogni ponte e tunnel in una metropoli in espansione possa resistere a un terremoto. Per fare ciò, gli ingegneri utilizzano strumenti automatizzati che scansionano il codice senza eseguirlo effettivamente, mappando ogni possibile percorso che un programma potrebbe intraprendere. Queste mappe, note come grafi di flusso di controllo, sono incredibilmente dettagliate e mostrano come un programma passi da un'istruzione all'altra. Tuttavia, queste mappe sono spesso troppo minuziose; evidenziano percorsi che sembrano pericolosi sulla carta ma che sono fisicamente impossibili da percorrere nel mondo reale. Ciò crea un'ondata di falsi allarmi, costringendo gli esperti umani a sprecare tempo nell'investigare fantasmi nella macchina. La sfida, quindi, è costruire un sistema in grado di distinguere rapidamente tra un percorso che è solo possibile in teoria e uno che è effettivamente eseguibile, senza perdersi nell'enorme volume di possibilità.
Un team di ricercatori dell'Università Russo-Armena ha sviluppato un nuovo metodo per risolvere questo problema, utilizzando una tecnica chiamata esecuzione simbolica diretta. Immaginate un viaggiatore che cerca di verificare se esiste un percorso specifico attraverso una città complessa. Un approccio standard sarebbe quello di inviare esploratori a percorrere ogni singola strada della città per vedere dove portano, un compito che richiederebbe un tempo infinito e sopraffarebbe la squadra. Invece, il metodo dei ricercatori agisce come un tour guidato. Prende un percorso specifico segnalato da uno scanner di sicurezza e dirige un esploratore virtuale a seguire solo quel percorso, ignorando ogni altra strada che non conduca alla destinazione. Questo approccio "diretto" permette al sistema di controllare se il pericolo segnalato è reale senza sprecare energia in deviazioni irrilevanti.
Il cuore di questo lavoro risiede nel modo in cui il sistema gestisce l'ignoto. Nel software reale, i programmi spesso trattano dati che non sono ancora stati impostati, o chiamano funzioni da librerie esterne dove il codice interno è nascosto. Un esploratore tradizionale potrebbe bloccarsi o arrendersi di fronte a questi vuoti. Il sistema dei ricercatori, invece, è progettato per trattare questi ignoti come variabili flessibili. Se un programma legge una posizione di memoria che non è stata ancora riempita, il sistema le assegna un valore simbolico, permettendogli di esplorare ogni possibile esito che quel valore potrebbe assumere. Fa lo stesso per i risultati di funzioni esterne e per argomenti di puntatori complessi, che agiscono come indirizzi dinamici che possono puntare a posti diversi a seconda della situazione. Riempendo automaticamente questi vuoti con delle possibilità anziché con ipotesi concrete, il sistema può tracciare il percorso attraverso il codice anche quando l'immagine completa non è visibile.
Un altro grande ostacolo nel navigare il software è il ciclo, una sezione di codice che si ripete. In un programma reale, un ciclo può girare alcune volte o milioni di volte, e in un'analisi simbolica può intrappolare l'esploratore in un ciclo infinito. I ricercatori hanno introdotto una strategia per gestire questo problema stabilendo un limite al numero di volte in cui il sistema seguirà un ciclo prima di costringerlo a uscire. Non si tratta di un distacco casuale; il sistema registra attentamente ciò che è accaduto durante quelle iterazioni e poi salta al punto in cui il ciclo terminerebbe naturalmente. Ciò consente all'analisi di proseguire oltre la sezione ripetitiva senza bloccarsi, garantendo che lo strumento possa raggiungere la fine del percorso che sta investigando.
Per testare il loro metodo, il team lo ha applicato a software reali e a una collezione standard di casi di test nota come suite Juliet. Hanno prima verificato il loro sistema rispetto ai percorsi estratti dai GNU Coreutils, un insieme fondamentale di strumenti per il sistema operativo Linux. Il sistema ha verificato con successo che il 95,3% di questi percorsi reali era effettivamente fattibile, dimostrando di poter gestire codice complesso e intrecciato. Successivamente, hanno integrato il loro metodo con uno strumento di sicurezza esistente chiamato MLH. Prima di questa aggiunta, lo strumento segnalava 666 falsi allarmi su migliaia di segnalazioni. Dopo l'applicazione della nuova analisi di fattibilità del percorso, quei falsi allarmi sono scomparsi completamente, mentre lo strumento continuava a rilevare ogni singola vulnerabilità reale che aveva trovato in precedenza. Ciò significa che la precisione del controllo di sicurezza è passata dal 56,6% al 100% sul sottoinsieme testato, senza alcuna perdita nella capacità di trovare bug reali.
I ricercatori hanno inoltre confrontato il loro approccio con KLEEF, un altro strumento specializzato progettato per compiti simili. Quando testato su segnalazioni generate da altri due importanti scanner di sicurezza, Infer e Clang Static Analyzer, i risultati sono stati netti. KLEEF ha faticato significativamente, fallendo nel verificare la maggior parte dei report di veri positivi e causando un crollo delle sue prestazioni. Al contrario, il nuovo metodo ha mantenuto o migliorato leggermente le prestazioni degli scanner originali. Ha verificato con successo tutti i veri vulnerabili segnalati dallo strumento Infer e ha gestito la stragrande maggioranza dei report di Clang, dimostrando di essere abbastanza robusto da lavorare con codice di livello industriale.
I risultati suggeriscono che questo approccio diretto offre un modo pratico per pulire il rumore nei test di sicurezza del software. Concentrandosi solo sui percorsi che contano e gestendo automaticamente le complessità della memoria e delle funzioni esterne, il metodo filtra gli scenari impossibili che fanno perdere tempo agli esseri umani. Sebbene il sistema faccia un compromesso calcolato limitando le iterazioni dei cicli per mantenere il ritmo, i risultati mostrano che ciò non avviene a scapito del mancato rilevamento di pericoli reali. Il lavoro fornisce una via chiara per rendere gli strumenti di sicurezza automatizzati più affidabili, assicurando che quando viene emesso un avviso, si tratti di una minaccia reale degna di essere investigata.
Sommerso dagli articoli nel tuo campo?
Ricevi digest giornalieri degli articoli più recenti corrispondenti alle tue parole chiave di ricerca — con riassunti tecnici, nella tua lingua.