💻 computer science

From TinyGo to gc Compiler: Extending Zorya's Concolic Framework to Real-World Go Binaries

Questo documento presenta un'estensione del framework di esecuzione concolica Zorya per supportare binari Go multi-thread compilati con il compilatore gc standard, consentendo il rilevamento di vulnerabilità reali in progetti di produzione come Kubernetes e Go-Ethereum ripristinando gli stati dei thread, neutralizzando la preemption runtime e impiegando un'analisi dei percorsi sovrapposti.

Autori originali: Karolina Gorna, Nicolas Iooss, Yannick Seurin, Rida Khatoun, Keith Makan

Pubblicato 2026-05-06

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Karolina Gorna, Nicolas Iooss, Yannick Seurin, Rida Khatoun, Keith Makan

Articolo originale sotto licenza CC BY 4.0 (http://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

Immagina di essere un ispettore di sicurezza che cerca trappole nascoste in una fabbrica enorme e complessa. Questa fabbrica è un software scritto nel linguaggio di programmazione Go.

Per molto tempo, gli ispettori di sicurezza hanno avuto uno strumento speciale chiamato Zorya che era eccellente nell'ispezionare piccole e semplici fabbriche (chiamate "binari TinyGo"). Ma le fabbriche del mondo reale utilizzate da grandi aziende come Kubernetes ed Ethereum sono enormi, caotiche e funzionano con molti operai (thread) contemporaneamente. Il vecchio strumento Zorya non riusciva a gestire queste grandi fabbriche; si confondeva a causa del rumore e della complessità.

Questo articolo riguarda l'aggiornamento di Zorya in modo che possa finalmente ispezionare queste fabbriche Go del mondo reale con più operai. Ecco come l'hanno fatto, spiegato semplicemente:

1. Il Problema: La "Fabbrica Affollata"

Il compilatore Go standard (chiamato gc) costruisce software che avvia un intero team di operai invisibili (thread del sistema operativo) solo per gestire il lavoro. Ha anche un "agente del traffico" (il runtime) che può fermare qualsiasi operaio in qualsiasi momento per far passare qualcun altro prima.

Il Vecchio Strumento: Zorya era usato per ispezionare fabbriche silenziose con un solo operaio. Quando provava a guardare le fabbriche affollate con più operai, non riusciva a capire chi stesse facendo cosa o dove si trovassero gli operai.
L'Obiettivo: Rendere Zorya abbastanza intelligente da mettere in pausa il caos, scattare una fotografia di ogni singolo operaio e poi ispezionare attentamente il lavoro senza perdersi.

2. La Soluzione: Tre Nuovi Superpoteri

Gli autori hanno dato a Zorya tre nuovi trucchi per gestire le grandi fabbriche:

Lo "Snapshot Viaggiatore nel Tempo" (Ripristino degli stati dei thread):
Immagina che la fabbrica stia funzionando a pieno regime. Invece di cercare di guardare gli operai muoversi in tempo reale (cosa troppo veloce e confusa), il nuovo Zorya preme "pausa", scatta una fotografia ad alta definizione delle mani, degli attrezzi e della posizione di ogni singolo operaio e la salva. Quando inizia la sua ispezione, ricarica queste fotografie così da sapere esattamente dove si trovava ognuno prima di iniziare. Questo gli permette di ignorare il caos dell'"agente del traffico" e concentrarsi sul codice effettivo.
Lo "Specchio Ipotesi" (Analisi del percorso di sovrapposizione):
Di solito, quando un operaio arriva a un bivio, sceglie un percorso e lo percorre. L'altro percorso viene ignorato.
- Il Vecchio Modo: Zorya controllava solo il percorso che l'operaio aveva effettivamente percorso.
- Il Nuovo Modo: Zorya crea uno "specchio fantasma" della fabbrica. Quando l'operaio sceglie il percorso di sinistra, Zorya invia un "operaio fantasma" lungo il percorso di destra per pochi passi. Controlla se quel percorso ha una trappola (come un buco nel pavimento o un attrezzo rotto) senza percorrerlo realmente. Se il fantasma trova una trappola, Zorya suona l'allarme. Questo è chiamato Copy-on-Write: copia solo le parti della fabbrica che il fantasma tocca, risparmiando una enorme quantità di energia.
Il Rilevatore di "Trappole Silenziose":
Alcune trappole non fanno rumore (come un crash o un panico). Ad esempio, un numero potrebbe diventare così grande da "avvolgersi" e diventare piccolo di nuovo, rompendo silenziosamente la matematica. Altri strumenti perdono queste trappole perché cercano solo crash rumorosi. Zorya utilizza un cervello matematico super-intelligente (chiamato risolutore SMT) per fare i calcoli nella sua mente. Può dire: "Ehi, se questo numero diventa più grande, romperà silenziosamente la matematica", anche se il programma non va in crash.

3. Il Test: Trovare Bug Reali

Il team ha testato questo Zorya aggiornato su 11 falle di sicurezza reali trovate in software famosi come Kubernetes, Go-Ethereum e CoreDNS. Hanno confrontato Zorya con altri strumenti come i controllori statici (che leggono il codice come un correttore grammaticale), i fuzzers (che lanciano dati casuali sul software) e altri scanner di sicurezza.

I Risultati:

Zorya ha trovato 7 bug su 11.
La Vittoria "Silenziosa": Uno dei bug trovati da Zorya era un "overflow intero silenzioso". Era un errore matematico che non faceva crashare il programma e non attivava alcun allarme. Nessun altro strumento ha trovato questo bug a meno che qualcuno non avesse indicato manualmente esattamente cosa cercare. Zorya lo ha trovato automaticamente.
Il Compromesso: Zorya è più lento degli strumenti che "lanciano dati casuali" (fuzzers). Mentre un fuzzer potrebbe trovare un crash in pochi secondi, Zorya impiega circa 16 minuti per trovare un bug. Tuttavia, Zorya non ha bisogno che una persona scriva uno script di test specifico per ogni singola funzione; analizza direttamente il file binario.

4. La Conclusione

Questo articolo dimostra che ora possiamo utilizzare ispezioni avanzate con "operai fantasma" per trovare falle di sicurezza profonde e nascoste in software Go complessi e multi-thread. Sebbene richieda un po' più di tempo rispetto ad altri metodi, può trovare bug "silenziosi" che altri strumenti perdono completamente, rendendo la nostra infrastruttura digitale più sicura.

In breve: Hanno insegnato a un robot di sicurezza come mettere in pausa una fabbrica caotica, scattare una fotografia degli operai e controllare i percorsi che nessun altro sta percorrendo, trovando con successo trappole nascoste che prima erano invisibili.

Riepilogo Tecnico: Da TinyGo al compilatore gc: Estensione del Framework Concolico di Zorya ai Binari Go Reali

Enunciato del Problema

L'analisi di sicurezza dei binari Go compilati con il compilatore standard gc rimane una sfida significativa. A differenza dei binari compilati con TinyGo (che producono eseguibili single-thread con runtime minimi), i binari compilati con gc utilizzano un runtime complesso che gestisce goroutine, garbage collection e scheduling preemptive su più thread del sistema operativo. Gli strumenti esistenti di esecuzione simbolica (ad esempio KLEE, angr, Radius2) sono progettati principalmente per C/C++ e si basano su rappresentazioni intermedie LLVM (IR) a cui Go non compila completamente. Inoltre, questi strumenti spesso falliscono nel modellare meccanismi specifici del runtime Go, come la preemption cooperativa/asincrona, lo scheduling delle goroutine e le funzioni VDSO mappate in memoria, rendendoli inefficaci contro i binari Go di produzione. Le iterazioni precedenti del framework Zorya erano limitate ai binari TinyGo, lasciando un vuoto nell'analisi di applicazioni Go reali e multi-thread.

Metodologia

Il documento presenta un'estensione di Zorya, un framework di esecuzione concolica che eleva i binari compilati alla rappresentazione intermedia P-Code di Ghidra. L'estensione abilita l'analisi di binari multi-thread compilati con gc attraverso tre meccanismi tecnici principali:

Ripristino dello Stato Multi-Thread e Scheduling:
- Zorya ripristina lo stato di tutti i thread del sistema operativo dai dump gdb all'inizializzazione, catturando gli stati dei registri, le basi dello storage locale per thread (TLS) e gli stack backtrace.
- I thread vengono classificati (ad esempio, thread principale, monitor di sistema, in attesa) per facilitare lo scheduling.
- Il framework neutralizza la preemption del runtime e adotta una politica di scheduling "solo principale" per l'analisi in modalità funzione, limitando l'esecuzione concolica al thread principale per evitare interruzioni da parte del garbage collection o dei monitor di sistema. Ciò consente un'esplorazione continua delle funzioni a livello utente.
Analisi dei Percorsi Sovrapposti con Semantica Copy-on-Write (CoW):
- Per affrontare l'esplosione dei percorsi e ragionare sui rami non presi senza forkare l'intero stato (che può superare 1 GiB per i binari gc), Zorya implementa un meccanismo di sovrapposizione (overlay).
- Quando un ramo condizionale coinvolge variabili simboliche tracciate, viene creato un overlay leggero per il percorso non preso. Le letture consultano prima l'overlay, ricorrendo allo stato di base in caso di mancato riscontro; le scritture vanno esclusivamente all'overlay.
- Questo overlay esegue un numero limitato di istruzioni (predefinito $N=15$ ) prima di essere scartato, consentendo il rilevamento di vulnerabilità su percorsi non percorsi dalla traccia concreta.
Rilevamento delle Vulnerabilità tramite Routine di Analisi:
- Il framework esegue le istruzioni sia con valori concreti (dal dump gdb) che con espressioni simboliche (gestite dal risolutore SMT Z3).
- Una "Routine di Analisi" verifica i pattern di vulnerabilità a ogni istruzione, inclusi dereferenzi di puntatori nulli, overflow interi e divisioni per zero.
- Per i binari gc, il sistema sfrutta sia l'esplorazione AST (per localizzare chiamate esplicite a panic) che l'esecuzione overlay (per rilevare vulnerabilità silenziose che non attivano panics del runtime).

Contributi Chiave

Estensione ai Binari gc: Il framework è stato esteso per analizzare binari multi-thread prodotti dal compilatore Go standard, colmando il divario tra strumenti di ricerca e software Go di produzione.
Dataset di Vulnerabilità Reali: Gli autori hanno curato un corpus di 11 vulnerabilità reali provenienti da progetti di produzione (inclusi Kubernetes, Go-Ethereum e CoreDNS), complete di flussi di lavoro di riproduzione e input attivatori.
Valutazione Comparativa: Zorya è stato valutato contro sette strumenti all'avanguardia (tre analizzatori statici, due fuzzer e due esecutori simbolici a livello di binario).
Rilevamento di Vulnerabilità Silenziose: Il framework rileva con successo vulnerabilità che non attivano panics del runtime, in particolare overflow interi silenziosi, senza richiedere oracoli scritti manualmente.

Risultati

La valutazione è stata condotta su 11 vulnerabilità reali appartenenti a tre classi: dereferenzi di puntatori nulli, overflow interi e indice fuori dai limiti.

Tasso di Rilevamento: Zorya ha rilevato 7 su 11 vulnerabilità.
- 4 sono state catturate dalla Routine di Analisi sul percorso concreto (preso).
- 3 sono state identificate tramite raggiungibilità del panic nell'AST sul ramo non preso.
- 2 risultati secondari sono emersi tramite esecuzione overlay su percorsi non presi (rilevati entro il limite di profondità di 15 istruzioni).
Rilevamento Unico: Zorya è stato l'unico strumento a rilevare un overflow intero silenzioso nella funzione memoryGasCost di Go-Ethereum (v1.6.0). Questo bug coinvolge una moltiplicazione che avvolge silenziosamente nell'aritmetica senza segno di Go, permettendo a un attaccante di allocare memoria massiccia per gas quasi nullo. Nessun altro strumento valutato ha trovato questo bug senza un oracolo scritto manualmente.
Confronto tra Strumenti:
- Analizzatori Statici (staticcheck, gosec, nilaway): Hanno rilevato 0 dei 11 bug. gosec ha mancato overflow aritmetici dello stesso tipo, e nilaway ha fallito sui pacchetti Kubernetes a causa di problemi di risoluzione delle dipendenze.
- Fuzzer (go test -fuzz, GoLibAFL): Hanno rilevato 5 dei 11 bug (incluso kube-sm-2025, che Zorya ha mancato a causa dell'esaurimento delle risorse nell'esecuzione simbolica di runtime.memmove). I fuzzer sono stati più veloci (media ~0,18s - 7s) ma richiedevano harness scritti manualmente e mancavano le vulnerabilità silenziose che non causano crash.
- Altri Esecutori Simbolici (BINSEC, SymQEMU): Hanno rilevato 0 dei 11 bug, principalmente a causa della mancanza di supporto per le primitive del runtime Go.
Prestazioni: Zorya ha mediato 16,5 minuti per rilevamento, significativamente più lento dei fuzzer, ma fornisce una traccia di esecuzione completa a livello di istruzione e opera completamente automaticamente senza harness.

Significato e Affermazioni

Il documento afferma che Zorya affronta un vuoto critico nel panorama della sicurezza Go. Mentre gli analizzatori statici falliscono nel ragionare su aritmetica specifica del programma e aliasing, e i fuzzer richiedono harness manuali e mancano bug non crashanti, Zorya offre un'analisi automatica a livello di binario capace di rilevare vulnerabilità silenziose.

Gli autori posizionano Zorya come uno strumento che combina esplorazione overlay fine, recupero dello stato iniziale multi-thread e rilevamento di overflow silenziosi specificamente per i binari Go. Il lavoro dimostra che l'esecuzione concolica può essere adattata al runtime complesso e multi-thread del compilatore Go standard, abilitando il rilevamento di vulnerabilità (come overflow interi silenziosi) invisibili agli altri strumenti valutati. Il documento conclude che, sebbene Zorya sia più lento del fuzzing, la sua capacità di fornire tracce esatte a livello di istruzione e di rilevare bug non crashanti lo rende un valido aggiunta al toolkit di ingegneria della sicurezza del software.