Pre-Model Representation Failures in GNN-Based Smart Contract Vulnerability Detection
Questo articolo presenta un'analisi dei guasti dei rilevatori di vulnerabilità di smart contract basati su GNN, rivelando che difetti critici nello strato di rappresentazione del grafo — quali liste bianche di variabili predefinite, ambiguità strutturali e mancanza di nodi semantici — possono causare la produzione di grafi differenti per lo stesso codice e la classificazione errata di contratti pienamente sfruttabili come sicuri, rendendo di fatto inefficaci i successivi miglioramenti del modello.
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
Nel mondo digitale della finanza decentralizzata, il denaro si muove attraverso programmi informatici auto-eseguibili chiamati smart contract. Questi programmi vivono su una blockchain, un registro pubblico che registra ogni transazione, e sono progettati per gestire asset reali senza intermediari umani. Poiché questi contratti gestiscono fondi preziosi, un singolo difetto nascosto può portare a un furto immediato e irreversibile. Per proteggersi da ciò, i ricercatori hanno sviluppato sistemi automatizzati che scansionano il codice per trovare debolezze prima che vengano sfruttate. Un approccio popolare utilizza un tipo di intelligenza artificiale nota come rete neurale a grafi. Per capire come funziona, immaginate di trasformare un complesso pezzo di codice in una mappa di punti e linee connesse, dove i punti rappresentano parti del programma e le linee mostrano come queste interagiscono. Il computer studia poi questa mappa per decidere se il programma è sicuro o pericoloso. La speranza è che, guardando la struttura del codice anziché leggerlo riga per riga, questi sistemi possano individuare trappole sottili che gli esseri umani potrebbero mancare.
Un team di ricercatori della Carnegie Mellon University Africa ha deciso di testare proprio la base di questo approccio. Si sono concentrati su un sistema specifico chiamato GNNSCVulDetector, ampiamente utilizzato per trovare un difetto pericoloso noto come reentrancy (rientranza). Questo difetto si verifica quando un programma invia denaro in uscita prima di aggiornare i propri registri, permettendo a un ladro di ingannare il sistema affinché paghi più di quanto dovrebbe. I ricercatori non hanno testato quanto bene il computer impari o quanto velocemente pensi. Invece, hanno indagato sul passaggio che avviene prima che il computer veda i dati: il processo di trasformazione del codice sorgente nella mappa. Volevano sapere se la mappa riflettesse accuratamente il codice che doveva rappresentare. La loro indagine ha rivelato una verità sorprendente: il processo di creazione della mappa era rotto in modi che nessuna quantità di addestramento avrebbe potuto risolvere.
Il primo problema che hanno riscontrato è stato che il sistema veniva facilmente ingannato da semplici modifiche al codice. I ricercatori hanno preso un contratto noto per essere vulnerabile e hanno semplicemente rinominato le sue parti, cambiando il nome del contratto stesso, i nomi delle sue funzioni e i nomi delle variabili che contenevano il denaro. Hanno anche aggiunto righe di codice che non facevano nulla, solo per ingombrare il file. In un mondo normale, queste modifiche renderebbero il programma diverso, anche se la logica pericolosa rimaneva la stessa. Tuttavia, quando i ricercatori hanno inserito sia l'originale che la versione modificata nel sistema, il computer ha prodotto mappe identiche fino all'ultimo byte. Il sistema non riusciva a distinguere tra le due. Ciò significa che un attaccante potrebbe aggirare il controllo di sicurezza semplicemente rinominando le variabili, senza bisogno di conoscere nulla di come funziona il rilevatore o su quali dati sia stato addestrato. Il sistema era cieco alla reale struttura del codice, vedendo solo un rigido schema di nomi.
Scavando più a fondo, i ricercatori hanno scoperto perché questo accadeva. Lo strumento che costruisce la mappa non legge e comprende realmente il codice come un programmatore umano. Invece, si affida a una lista predefinita di quarantasette nomi di variabili specifici che è autorizzato a riconoscere. Se il codice usa un nome presente in questo elenco, lo strumento crea un nodo sulla mappa. Se il nome non è nell'elenco, lo strumento lo ignora o crea un segnaposto generico. I ricercatori hanno testato questo aspetto creando quattro contratti diversi che avevano tutti lo stesso difetto pericoloso, ma utilizzavano nomi diversi per le variabili del denaro. Quando il nome della variabile corrispondeva perfettamente alla lista, la mappa appariva normale. Quando il nome era leggermente diverso, la mappa cambiava in modi confusi. Quando il nome era completamente nuovo e non presente nell'elenco, la mappa diventava degradata, perdendo dettagli importanti. Nel caso peggiore, quando nessun nome corrispondeva affatto, lo strumento fabbricava parti della mappa che non esistevano nel codice originale, creando una struttura basata su nulla se non sulle proprie regole interne. Ciò significava che la qualità della mappa dipendeva interamente dal fatto che il programmatore utilizzasse uno dei quarantasette nomi approvati.
Il secondo fallimento importante riguardava una parte specifica della mappa che rappresenta l'attaccante. Nel design del sistema, esiste un nodo destinato a rappresentare il chiamante esterno (external caller) — l'entità esterna che innesca l'attacco. Affinché esista un difetto di reentrancy, questo chiamante esterno deve essere presente nella mappa. I ricerci hanno scoperto che, per l'esempio più famoso di contratto vulnerabile presente in letteratura, questo nodo era completamente assente. Lo strumento non è riuscito a disegnare la connessione tra l'attaccante e la funzione vulnerabile, anche se il codice mostrava chiaramente che ciò accadeva. Questo non era un limite del design della mappa, poiché altri contratti nei dati di addestramento mostravano questa connessione. Era un'incoerenza nel modo in cui lo strumento decideva di costruire la mappa. Poiché la connessione mancava, il computer non aveva modo di vedere il pattern di attacco, anche se il pattern era presente nel codice.
Per dimostrare che questo pezzo mancante causava il fallimento del sistema, i ricercatori hanno costruito un contratto minimo, creato appositamente, che conteneva un difetto di reentrancy pienamente sfruttabile. Hanno utilizzato un nome di variabile che era noto per essere nell'elenco approvato, assicurandosi che il primo problema con la rinomina non interferisse. Hanno inserito questo contratto nel sistema. Il risultato è stata una chiara classificazione errata: il sistema ha etichettato il contratto pericoloso come sicuro. La ragione era semplice e diretta. Poiché lo strumento non riusciva a disegnare la connessione tra il chiamante esterno e la funzione vulnerabile, la mappa mancava del segnale critico necessario per identificare la minaccia. Il computer non era sbagliato nel suo calcolo; stava semplicemente lavorando con un'immagine incompleta. L'informazione necessaria per prendere la decisione corretta era stata scartata prima ancora che il computer iniziasse a pensare.
Queste scoperte suggeriscono che gli elevati numeri di accuratezza riportati negli studi precedenti siano fuorvianti, poiché sono stati misurati in condizioni che non esponevano questi difetti. I sistemi funzionavano bene solo perché i dati di test utilizzavano i nomi e i pattern specifici che lo strumento poteva riconoscere. Nel mondo reale, dove il codice viene scritto con diverse convenzioni di denominazione e strutture, questi sistemi potrebbero fallire silenziosamente. I ricercatori sottolineano che migliorare il modello di intelligenza artificiale in sé non risolverà questo problema. Nessuna quantità di migliore addestramento o di più dati può riparare una mappa che è stata disegnata in modo errato fin dall'inizio. La soluzione richiede di cambiare il modo in cui il codice viene convertito in una mappa, passando da un semplice abbinamento di nomi a una comprensione più profonda di ciò che il codice effettivamente fa. Finché la base non sarà sistemata, i sistemi di sicurezza costruiti su di essa rimarranno vulnerabili proprio agli attacchi che sono nati per prevenire.
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.