In questo articolo Indice dei contenuti 3 sezioni
Due falle di sicurezza hanno permesso a chi sapeva dove guardare di scavalcare la sandbox di OpenAI Codex e arrivare direttamente al sistema operativo del computer su cui girava l’agente. Non un dettaglio marginale, perché l’intero senso di un ambiente isolato sta proprio nel garantire che il codice eseguito resti confinato. I ricercatori di Accomplish hanno individuato due tecniche indipendenti, battezzate Heapjack e Overpatch, e le hanno segnalate a OpenAI nelle settimane scorse. Entrambe sono già state corrette. Il punto in comune tra le due vulnerabilità racconta molto più del singolo bug. In entrambi i casi, una parte del meccanismo che doveva applicare le restrizioni si trovava all’interno dello stesso ambiente che avrebbe dovuto tenere sotto controllo. Una specie di guardiano chiuso nella stessa stanza dei sorvegliati, con tutto quello che ne consegue quando qualcuno decide di frugare nei cassetti.
Heapjack, quando il segreto resta nella stessa memoria
La prima tecnica colpiva noderepl, un componente installato da Codex Desktop e configurato tramite il file ~/.codex/config.toml. Il sistema separava codice affidabile e codice non affidabile usando contesti JavaScript distinti, una soluzione sensata sulla carta. Il problema è che quei due contesti condividevano lo stesso heap di memoria. Risultato: il segreto usato per distinguere le richieste autorizzate era in linea teorica raggiungibile anche dal codice confinato nella sandbox.
I ricercatori hanno sfruttato la funzione v8.getHeapSnapshot() per analizzare la memoria del processo e tirare fuori il valore necessario a costruire una richiesta privilegiata. Con quel token in mano, il codice poteva parlare con il processo genitore e usare funzionalità che la sandbox non copriva affatto. Il proof of concept ha mostrato l’avvio di applicazioni tramite il comando di sistema open e l’accesso a socket Unix. C’è un aspetto che merita più attenzione degli altri. Heapjack funzionava anche in modalità read only, quindi senza che l’agente avesse normalmente il permesso di modificare i file. Tradotto in pratica: bastava aprire un repository non fidato nell’ambiente vulnerabile per trasformarlo nel trampolino verso un’esecuzione di comandi sul PC host.
Overpatch e i permessi di scrittura che si allargano
La seconda falla riguardava Codex CLI e più precisamente applypatch, lo strumento con cui l’agente modifica i file. Nella modalità workspace write l’agente dovrebbe restare chiuso dentro la directory del progetto, niente di più. Solo che il sistema ricavava l’autorizzazione dal percorso indicato nella patch stessa, e questo apriva uno spiraglio abbastanza ampio.
Inserendo /tmp nel percorso, il controllo finiva per concedere permessi di scrittura fino alla radice del disco. Una seconda modifica sfruttava poi un link simbolico per arrivare al file .zshrc nella directory home dell’utente, quello che viene letto a ogni apertura del terminale. Tutto questo senza che venisse mostrata alcuna richiesta di approvazione, che è la parte più scomoda della faccenda: l’utente non avrebbe visto passare nulla.
Le patch e le versioni da installare
OpenAI ha messo mano a entrambi i problemi dopo la segnalazione, e piuttosto in fretta. Heapjack è stato corretto nella build 26.818.21641 di Codex Desktop, mentre Overpatch è stato risolto con Codex CLI 0.149.0. Accomplish riferisce che gli interventi sono arrivati entro otto giorni dalla comunicazione delle due vulnerabilità, un tempo di reazione che nel settore non è affatto scontato.
Per chi usa questi strumenti quotidianamente la contromisura concreta è una sola e non richiede particolari competenze: portare i componenti almeno alle versioni indicate, oppure a release più recenti. Fino a quel momento un repository non fidato aperto in Codex resta un rischio reale, non teorico, perché i proof of concept dei ricercatori hanno dimostrato che l’uscita dalla sandbox era perfettamente praticabile.
Fonte: TecnoAndroid
