💻 computer science

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

Dit artikel presenteert een uitbreiding van het Zorya-concolische-uitvoeringskader om multi-threaded Go-binarieën, gecompileerd met de standaard gc-compiler, te ondersteunen, waardoor het detecteren van kwetsbaarheden uit de echte wereld in productieprojecten zoals Kubernetes en Go-Ethereum mogelijk wordt door thread-staten te herstellen, runtime-preemptie te neutraliseren en overlay-paadanalyse toe te passen.

Oorspronkelijke auteurs: Karolina Gorna, Nicolas Iooss, Yannick Seurin, Rida Khatoun, Keith Makan

Gepubliceerd 2026-05-06

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Karolina Gorna, Nicolas Iooss, Yannick Seurin, Rida Khatoun, Keith Makan

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een veiligheidsinspecteur bent die probeert verborgen valstrikken te vinden in een enorme, complexe fabriek. Deze fabriek is een stuk software geschreven in de Go-programmeertaal.

Lange tijd hadden veiligheidsinspecteurs een speciaal hulpmiddel genaamd Zorya dat uitstekend was in het inspecteren van kleine, eenvoudige fabrieken (zogenaamde "TinyGo"-binaries). Maar de fabrieken uit de echte wereld die worden gebruikt door grote bedrijven zoals Kubernetes en Ethereum zijn enorm, chaotisch en draaien tegelijkertijd op vele arbeiders (threads). Het oude Zorya-hulpmiddel kon deze grote fabrieken niet aan; het raakte in de war door het lawaai en de complexiteit.

Dit artikel gaat over het upgraden van Zorya zodat het eindelijk deze fabrieken uit de echte wereld met meerdere arbeiders in Go kan inspecteren. Hier is hoe ze dat deden, eenvoudig uitgelegd:

1. Het Probleem: De "Drukkende Fabriek"

De standaard Go-compiler (genaamd gc) bouwt software die een heel team van onzichtbare arbeiders (OS-threads) opstart om het werk te beheren. Het heeft ook een "verkeersregelaar" (de runtime) die op elk moment elke arbeider kan stoppen om iemand anders de voorrang te geven.

Het Oude Hulpmiddel: Zorya werd gebruikt om rustige fabrieken met één arbeider te inspecteren. Toen het probeerde drukke fabrieken met meerdere arbeiders te bekijken, kon het niet uitzoeken wie wat deed of waar de arbeiders stonden.
Het Doel: Zorya slim genoeg maken om het chaos te pauzeren, een momentopname van elke arbeider te nemen en vervolgens het werk zorgvuldig te inspecteren zonder verdwaald te raken.

2. De Oplossing: Drie Nieuwe Superkrachten

De auteurs gaven Zorya drie nieuwe trucs om de grote fabrieken aan te kunnen:

De "Tijdsreis-Momentopname" (Herstellen van Thread-staten):
Stel je voor dat de fabriek op volle snelheid draait. In plaats van te proberen de arbeiders in real-time te volgen (wat te snel en verwarrend is), drukt de nieuwe Zorya op "pauze", maakt een hoogwaardige foto van de handen, gereedschappen en locatie van elke enkele arbeider en slaat deze op. Wanneer het zijn inspectie start, laadt het deze foto's weer in zodat het precies weet waar iedereen was voordat het begon. Hierdoor kan het het lawaai van de "verkeersregelaar" negeren en zich richten op de daadwerkelijke code.
De "Wat-als" Spiegel (Overlay Path-analyse):
Normaal gesproken, wanneer een arbeider een splitsing in de weg bereikt, kiest hij één pad en loopt die uit. Het andere pad wordt genegeerd.
- De Oude Manier: Zorya controleerde alleen het pad dat de arbeider daadwerkelijk nam.
- De Nieuwe Manier: Zorya creëert een "spookspiegel" van de fabriek. Wanneer de arbeider het linkerpad kiest, stuurt Zorya een "spookarbeider" het rechterpad op voor slechts een paar stappen. Het controleert of dat pad een valstrik heeft (zoals een gat in de vloer of een kapot gereedschap) zonder het daadwerkelijk te bewandelen. Als het spook een valstrik vindt, geeft Zorya alarm. Dit heet Copy-on-Write: het kopieert alleen de delen van de fabriek die het spook aanraakt, wat enorm veel energie bespaart.
De "Stille Valstrik"-Detector:
Sommige valstrikken maken geen luid geluid (zoals een crash of een panic). Bijvoorbeeld, een getal kan zo groot worden dat het "omslaat" en weer klein wordt, waardoor de wiskunde stilzwijgend kapot gaat. Andere tools missen deze omdat ze alleen zoeken naar harde crashes. Zorya gebruikt een superslim wiskundig brein (genaamd een SMT-oplosser) om de wiskunde in zijn hoofd te doen. Het kan zeggen: "Hé, als dit getal groter wordt, zal het de wiskunde stilzwijgend kapotmaken", zelfs als het programma niet crasht.

3. De Test: Echte Bugs Vinden

Het team testte deze opgegradueerde Zorya op 11 echte beveiligingsgaten die werden gevonden in beroemde software zoals Kubernetes, Go-Ethereum en CoreDNS. Ze vergeleken Zorya met andere tools zoals statische checkers (die code lezen als een grammaticacontrole), fuzzers (die willekeurige data op de software gooien) en andere beveiligingsscanners.

De Resultaten:

Zorya vond 7 van de 11 bugs.
De "Stille" Overwinning: Een van de bugs die Zorya vond, was een "stille integer overflow". Het was een rekenfout die het programma niet liet crashen en geen alarm deed afgaan. Geen enkele andere tool vond deze bug tenzij iemand hen handmatig precies had verteld waar ze naar moesten zoeken. Zorya vond het automatisch.
De Afweging: Zorya is trager dan de tools die "willekeurige data gooien" (fuzzers). Waar een fuzzer misschien binnen seconden een crash vindt, duurt het ongeveer 16 minuten voor Zorya om een bug te vinden. Echter, Zorya heeft geen mens nodig om een specifiek testschript voor elke functie te schrijven; het analyseert het binary-bestand direct.

4. De Conclusie

Dit artikel toont aan dat we nu geavanceerde "spookarbeider"-inspecties kunnen gebruiken om diepe, verborgen beveiligingsgaten te vinden in complexe, multi-threaded Go-software. Hoewel het iets langer duurt dan andere methoden, kan het "stille" bugs vinden die andere tools volledig missen, waardoor onze digitale infrastructuur veiliger wordt.

Kortom: Ze leerden een beveiligingsrobot hoe het een chaotische fabriek moet pauzeren, een momentopname van de arbeiders moet nemen en de paden moet controleren die niemand anders bewandelt, waardoor het succesvol verborgen valstrikken vond die voorheen onzichtbaar waren.

Technische Samenvatting: Van TinyGo naar gc-compiler: Uitbreiding van Zorya's Concolic Framework naar Real-World Go Binaries

Probleemstelling

Veiligheidsanalyse van Go-binaries gecompileerd met de standaard gc-compiler blijft een aanzienlijke uitdaging. In tegenstelling tot binaries gecompileerd met TinyGo (die single-threaded uitvoerbare bestanden produceren met minimale runtimes), maken gc-gecompileerde binaries gebruik van een complexe runtime die goroutines, garbage collection en preemptieve scheduling beheert over meerdere OS-threads. Bestaande symbolische uitvoeringstools (zoals KLEE, angr, Radius2) zijn primair ontworpen voor C/C++ en vertrouwen op LLVM-intermediaire representaties (IR) waarvoor Go niet volledig compileert. Bovendien falen deze tools vaak om Go-specifieke runtime-mechanismen te modelleren, zoals cooperatieve/asynchrone preemptie, goroutine-scheduling en memory-mapped VDSO-functies, waardoor ze inefficiënt zijn tegen productie-Go-binaries. Vorige iteraties van het Zorya-framework waren beperkt tot TinyGo-binaries, waardoor er een gat bleef in de analyse van real-world, multi-threaded Go-toepassingen.

Methodologie

Het artikel presenteert een uitbreiding van Zorya, een concolic uitvoeringsframework dat gecompileerde binaries omhooghaalt naar Ghidra's P-Code-intermediaire representatie. De uitbreiding maakt analyse mogelijk van multi-threaded gc-gecompileerde binaries via drie primaire technische mechanismen:

Multi-Thread State Herstel en Scheduling:
- Zorya herstelt de staat van alle OS-threads vanuit gdb-dumps bij initialisatie, waarbij registerstaten, thread-locale opslag (TLS)-bases en backtraces worden vastgelegd.
- Threads worden geclassificeerd (bijvoorbeeld hoofdthread, systeemmonitor, wachtend) om scheduling te faciliteren.
- Het framework neutraliseert runtime-preemptie en hanteert een "alleen hoofdthread"-schedulingbeleid voor analyse in functiemodus, waarbij concolic uitvoering wordt beperkt tot de hoofdthread om onderbrekingen door garbage collection of systeemmonitors te voorkomen. Dit staat continue exploratie van gebruikersniveau-functies toe.
Overlay Path Analyse met Copy-on-Write (CoW) Semantiek:
- Om padexplosie aan te pakken en redenering over niet-afgelegde takken mogelijk te maken zonder de volledige staat te forkeren (wat meer dan 1 GiB kan bedragen voor gc-binaries), implementeert Zorya een overlay-mechanisme.
- Wanneer een conditionele tak betrekking heeft op bijgehouden symbolische variabelen, wordt een lichtgewicht overlay gemaakt voor de niet-afgelegde tak. Lezingen raadplegen eerst de overlay en vallen terug op de basisstaat bij een miss; schrijvingen gaan uitsluitend naar de overlay.
- Deze overlay voert een begrensd aantal instructies uit (standaard $N=15$ ) voordat het wordt verwijderd, waardoor het detecteren van kwetsbaarheden op paden mogelijk is die niet door de concrete trace zijn afgelegd.
Kwetsbaarheidsdetectie via Analyzer Routine:
- Het framework voert instructies uit met zowel concrete waarden (uit de gdb-dump) als symbolische expressies (beheerd door de Z3 SMT-oplosser).
- Een "Analyzer Routine" controleert bij elke instructie op kwetsbaarheidspatronen, waaronder null-pointer dereferenties, integer overflows en deling door nul.
- Voor gc-binaries maakt het systeem gebruik van zowel AST-exploratie (om expliciete panic-aanroepen te lokaliseren) als overlay-uitvoering (om stille kwetsbaarheden te detecteren die geen runtime-panics veroorzaken).

Belangrijkste Bijdragen

Uitbreiding naar gc-Binaries: Het framework is uitgebreid om multi-threaded binaries te analyseren die zijn geproduceerd door de standaard Go-compiler, waardoor de kloof tussen onderzoekstools en productie-Go-software wordt overbrugd.
Real-World Kwetsbaarheidsdataset: De auteurs hebben een corpus samengesteld van 11 real-world kwetsbaarheden uit productieprojecten (waaronder Kubernetes, Go-Ethereum en CoreDNS), compleet met reproduceerwerkflows en triggerende invoer.
Vergelijkende Evaluatie: Zorya werd geëvalueerd tegenover zeven state-of-the-art tools (drie statische analyzers, twee fuzzers en twee symbolische uitvoerders op binary-niveau).
Detectie van Stille Kwetsbaarheden: Het framework detecteert succesvol kwetsbaarheden die geen runtime-panics veroorzaken, specifiek stille integer overflows, zonder dat handmatig geschreven orakels nodig zijn.

Resultaten

De evaluatie werd uitgevoerd op 11 real-world kwetsbaarheden verdeeld over drie klassen: Nil-pointer dereferenties, Integer overflows en Index out-of-bounds.

Detectiepercentage: Zorya detecteerde 7 van de 11 kwetsbaarheden.
- 4 werden gevangen door de Analyzer Routine op het concrete (afgelegde) pad.
- 3 werden geïdentificeerd via AST-panic-reachability op de niet-afgelegde tak.
- 2 zijwaartse bevindingen kwamen naar boven via overlay-uitvoering op niet-afgelegde paden (gedetecteerd binnen het 15-instructie dieptelimiet).
Unieke Detectie: Zorya was de enige tool die een stille integer overflow detecteerde in de memoryGasCost-functie van Go-Ethereum (v1.6.0). Deze bug houdt een vermenigvuldiging in die stil omloopt in Go's unsigned-aritmetiek, waardoor een aanvaller enorme hoeveelheden geheugen kan toewijzen voor bijna nul gas. Geen enkele andere geëvalueerde tool vond deze bug zonder een handmatig geschreven orakel.
Toolvergelijking:
- Statische Analyzers (staticcheck, gosec, nilaway): Detecteerden 0 van de 11 bugs. gosec miste aritmetische overflows van hetzelfde type, en nilaway faalde bij Kubernetes-pakketten vanwege problemen met afhankelijkheidsoplossing.
- Fuzzers (go test -fuzz, GoLibAFL): Detecteerden 5 van de 11 bugs (inclusief kube-sm-2025, die Zorya miste door hulpbronnenuitputting bij de symbolische uitvoering van runtime.memmove). Fuzzers waren sneller (gemiddeld ~0,18s tot 7s) maar vereisten handmatig geschreven harnessen en misten stille kwetsbaarheden die niet tot crashes leiden.
- Andere Symbolische Uitvoerders (BINSEC, SymQEMU): Detecteerden 0 van de 11 bugs, voornamelijk door gebrek aan ondersteuning voor Go-runtime-primitieven.
Prestaties: Zorya nam gemiddeld 16,5 minuten per detectie in beslag, aanzienlijk trager dan fuzzers, maar biedt een volledige instructie-niveau uitvoeringstrace en werkt volledig automatisch zonder harnessen.

Betekenis en Claims

Het artikel stelt dat Zorya een kritiek gat in het Go-beveiligingslandschap aanpakt. Waar statische analyzers falen in het redeneren over programma-specifieke aritmetiek en aliasing, en fuzzers handmatige harnessen vereisen en niet-crashende bugs missen, biedt Zorya een volledig automatische analyse op binary-niveau die in staat is stille kwetsbaarheden te detecteren.

De auteurs positioneren Zorya als een tool die fijne overlay-exploratie, herstel van multi-thread initiële staat en detectie van stille overflows combineert, specifiek voor Go-binaries. Het werk toont aan dat concolic uitvoering kan worden aangepast aan de complexe, multi-threaded runtime van de standaard Go-compiler, waardoor detectie van kwetsbaarheden (zoals stille integer overflows) mogelijk wordt die onzichtbaar zijn voor andere geëvalueerde tools. Het artikel concludeert dat, hoewel Zorya trager is dan fuzzing, het vermogen om exacte instructie-niveau traces te leveren en niet-crashende bugs te detecteren, het een waardevolle aanvulling maakt op de toolkit voor softwarebeveiligingsengineering.