The Pulse
NameTrap mostra come i nomi delle variabili possano indurre gli agenti di programmazione a introdurre vulnerabilità
Un articolo scientifico presentato ad arXiv il 25 ottobre descrive NameTrap, un attacco che modifica gli identificatori nei file Python per influenzare gli agenti di programmazione basati sull’IA. Su sei agenti, i ricercatori hanno rilevato
AI.info Team · Scritto con l’IA · verificato ·
Rinominare le variabili non dovrebbe cambiare il comportamento di un programma. Ma negli esperimenti descritti in un articolo scientifico presentato ad arXiv il 25 ottobre, modificare gli identificatori in normali file Python ha spinto gli agenti di programmazione a scrivere codice con specifiche debolezze di sicurezza. L’attacco NameTrap dei ricercatori non aggiunge ai file istruzioni malevole né codice vulnerabile: si affida a nomi che influenzano il modo in cui un agente interpreta il codice incompleto.
Il risultato mette in contrasto due modi di leggere un file di codice. Per un programma convenzionale, rinominare gli identificatori in modo coerente può preservarne il comportamento; per un agente di programmazione che completa quel programma, i nuovi nomi possono cambiare gli indizi in base ai quali decide quale codice scrivere. I ricercatori scrivono: «Mostriamo che questo contesto proveniente dal Web può essere usato come arma senza alcuna istruzione esplicita». Chieh-Yuan Chang et al., autori di «NameTrap: Steering AI Coding Agents Toward Security Vulnerabilities via Variable Names»
NameTrap lascia ancora da scrivere il codice vulnerabile
I ricercatori hanno testato la tecnica su 200 file Python incompleti tratti da 31 progetti fra i 100 con più stelle su GitHub. Hanno prima selezionato i file: perché un file fosse considerato un punto di partenza privo della debolezza, nessuno di dieci tentativi di completamento doveva produrre la debolezza presa di mira. Il test ha riguardato sei agenti di programmazione, dieci modelli linguistici sottostanti e quattro categorie della Common Weakness Enumeration: iniezione di comandi del sistema operativo, cross-site scripting, crittografia rischiosa e deserializzazione non sicura.
Per creare l’esca, un agente dalla parte dell’attaccante modifica gli identificatori in modo da suggerire una convenzione associata alla debolezza scelta. I nomi possono, per esempio, far pensare che i dati siano attendibili o che la compatibilità richieda un digest veloce. In una sessione di prova separata, viene chiesto a un agente di completare il file modificato e il risultato viene poi controllato con Bandit e Semgrep. Se nessuno dei due scanner segnala la debolezza presa di mira, l’attaccante può provare a rinominare nuovamente gli identificatori; il file rilasciato è il codice rinominato e ancora incompleto, non il completamento vulnerabile.
I tassi di successo dipendevano dall’agente e dal modello
Tra i sei agenti di programmazione, i tassi complessivi di successo dell’attacco NameTrap andavano dal 22,5% al 56,0%, contro tassi complessivi inferiori nelle condizioni di confronto dello studio basate su rinomina casuale, rinomina neutra e XOXO. Aider ha registrato il tasso complessivo più alto, il 56,0%, mentre OpenHands ha registrato il 22,5%. Per particolari combinazioni di agente e modello, l’articolo riporta un tasso fino al 75,0%.
Queste cifre descrivono esperimenti controllati di completamento, non attacchi confermati contro software in uso. Un tentativo era considerato riuscito quando il codice generato conteneva una debolezza presa di mira che Bandit o Semgrep segnalavano con gravità media o superiore. Gli autori hanno inoltre riscontrato notevoli differenze tra modelli e framework: lo stesso modello raggiungeva tassi diversi con agenti diversi e alcune combinazioni non producevano alcuna esca che soddisfacesse i criteri.
I file rinominati sfuggivano ai controlli rivolti alle vulnerabilità già presenti
Secondo i ricercatori, NameTrap rimaneva efficace con prompt in cinese tradizionale e alcune esche funzionavano anche su modelli diversi. L’effetto non era uniforme: i tassi di trasferimento variavano tra coppie di modelli e alcune non producevano attacchi riusciti. Anche un promemoria sulla sicurezza non riusciva a impedire in modo sistematico che la debolezza presa di mira comparisse nel codice generato.
Tre analizzatori di sicurezza basati sull’IA e quattro analizzatori statici non hanno segnalato le debolezze prese di mira nei file sorgente alterati. Questo risultato ha un limite preciso: i file esca non contenevano istruzioni vulnerabili del tipo preso di mira da rilevare. La vulnerabilità compariva solo dopo che un agente separato aveva completato il codice: controllare la modifica finita riguarda quindi una fase diversa dal controllo del file che l’agente legge inizialmente.
L’articolo indica la necessità di controllare le modifiche generate
Gli autori raccomandano di trattare gli identificatori nel codice di terze parti come input non attendibili, anziché come specifiche, di sottoporre ad analisi di sicurezza le modifiche generate dagli agenti prima di confermarle e di registrare quali file esterni hanno influenzato ogni modifica. Queste misure concentrano la revisione sul codice prodotto dall’agente e sul contesto che lo ha influenzato, invece di presumere che un file sorgente dall’aspetto innocuo non possa incidere su un’implementazione successiva.
La distinzione centrale di NameTrap è tra modificare il comportamento di un programma e modificare il modo in cui un agente lo interpreta. Negli esperimenti, la sola rinomina lasciava intatta la funzionalità già presente nel file sorgente; la debolezza di sicurezza compariva nel codice scritto successivamente dall’agente.