L’app-server Codex di OpenAI, usato per integrare il modello in client esterni, espone un’interfaccia JSON-RPC che consente l’esecuzione di comandi sul sistema ospitante. La documentazione avvisa dei rischi, ma non impone vincoli tecnici: avviando il servizio su tutte le interfacce senza autenticazione, è possibile invocare command/exec da remoto. Il problema è l’esposizione di un canale privilegiato senza protezione. L’uso deve essere limitato a contesti fidati e l’autenticazione abilitata per accessi remoti.
Il backend dell’App Codex, sviluppato da OpenAI, è il componente server locale che consente di collegare il backend con i client esterni. Alcuni esempi possono essere applicazioni, strumenti di sviluppo o soluzioni personalizzate.
Il backend espone una sua interfaccia basata su JSON-RPC, attraverso la quale il client può inizializzare una specifica sessione e inviare le richieste operative e ricevere anche patch in tempo reale. Si tratta, in buona sostanza, dell’interfaccia di controllo utilizzata per integrare Codex con i client esterni.
Nella documentazione ufficiale viene descritto che il componente è destinato principalmente ad ambienti locali o fidati, con esempi di utilizzo attraverso stdio oppure websocket su una interfaccia di loopback, come ad esempio ws://127.0.0.1:4500.
E’ presenta anche un metodo command/exec, il quale consente al client di richiedere l’esecuzione di comandi eseguiti sul sistema ospite. Si tratta di una capacità che è stata documentata, che rende il backend una interfaccia con privilegi operativi diretti sul sistema.
Leggendo il codice, il CERT-AgiD ha compreso che il sistema è consapevole dei rischi legati all’esposizione diretta nella rete. Quando l’esposizione del servizio è limitata ad una interfaccia di loopback, viene suggerito l’utilizzo di canali protetti.
Quando invece viene esposto su indirizzi non locali, il software segnala la necessità di configurare un meccanismo di autenticazione prima di utilizzarlo.

Questi elementi hanno dimostrato che il rischio è noto, e il sistema non applica nessun vincolo tecnico che impedisca questa specifica configurazione. Il servizio si avvia su tutte le interfacce di rete anche senza autenticazione, anche se si limita a mostrare un warning a runtime.
Durante una connessione websocket viene accettata una connessine senza credenziali e, completato l’handshake iniziale, il client può accedere al set di API, incluse quelle che permettono l’esecuzione di comandi sul sistema.

La documentazione relativa al sandboxing, descrive il confinamento, ma tale protezione non si estende all’accesso e all’interfaccia di controllo, che può risultare esposta in rete senza una autenticazione implementata.
Le verifiche effettuate svolte dal CERT-AgiD confermano che avviando il servizio con il binding all’indirizzo 0.0.0.0 senza autenticazione, è possibile attivare una connessione senza credenziali e invocare command/exec, ottenendo l’esecuzione dei comandi con restituzione dell’output.

Nella configurazione presa in esame non è stato necessario in alcun modo abilitare delle modalità particolari o disattivare esplicitamente il sandboxing. Il comportamento deriva dalla configurazione di default/attiva del server, la quale ha consentito l’esecuzione di comandi arbitrari, come nmap già presenti sul server.
Il problema non è l’esistenza di command/exec, ma il fatto che una specifica API, con capacità di controllo diretto e completo sul sistema, possa essere esposta nella rete tramite delle configurazioni non supportate e senza alcun vincolo tecnico che ne impedisca l’avvio in assenza di protezioni.
L’app-server può quindi diventare un punto di accesso remoto per dei malintenzionati, con capacità di esecuzione comandi sul sistema. Il rischio non deriva quindi dal lancio di exploit tradizionali, ma dall’esposizione di un canale di comunicazione che risulta essere privilegiato, senza una autenticazione obbligatoria e senza valori di default sicuri.
Dal punto di vista del prodotto, conclude il CERT-AgID, sarebbe auspicabile che Open AI introducesse meccanismi di hardening che impediscano l’avvio dei listener non locali in assenza di autenticazione.