L’app-server di Codex, sviluppato da OpenAI, è il componente di back-end che consente di collegare Codex a client esterni, come ad esempio applicazioni, strumenti di sviluppo o soluzioni personalizzate. Espone un’interfaccia basata su JSON-RPC attraverso cui un client può inizializzare una sessione, inviare richieste operative e ricevere aggiornamenti in tempo reale. Si tratta, in sostanza, dell’interfaccia di controllo usata per integrare Codex in client esterni.

La documentazione ufficiale descrive questo componente come destinato principalmente ad ambienti locali o fidati, con esempi di utilizzo tramite stdio oppure tramite websocket su interfaccia loopback, ad esempio ws://127.0.0.1:4500.

Tra le funzionalità esposte è presente anche il metodo command/exec, che consente al client di richiedere l’esecuzione di comandi sul sistema ospitante. Si tratta di una capacità documentata e intenzionale, che rende l’app-server un’interfaccia con privilegi operativi diretti sul sistema.

I suggerimenti nel codice

Dalla lettura del codice emerge che il sistema è consapevole dei rischi legati all’esposizione in rete. Quando l’esposizione del servizio è limitata all’interfaccia di loopback, viene suggerito l’uso di canali protetti per accessi remoti. Quando invece viene esposto su indirizzi non locali, il software segnala esplicitamente la necessità di configurare un meccanismo di autenticazione prima del suo utilizzo.

Avvisi presenti ma non vincolanti

Questi elementi dimostrano che il rischio è noto. Tuttavia, il sistema non applica alcun vincolo tecnico che impedisca configurazioni non sicure dello stesso. Il servizio può essere avviato su tutte le interfacce di rete anche in assenza di autenticazione, limitandosi a mostrare un warning a runtime.

La connessione websocket può essere accettata senza credenziali e, una volta completato l’handshake iniziale, il client può accedere all’intero set di API, incluse quelle che consentono l’esecuzione di comandi sul sistema.

Evidenze sperimentali

La documentazione sul sandboxing descrive il confinamento dei processi eseguiti, ma tale protezione non si estende all’accesso all’interfaccia di controllo, che può risultare esposta in rete senza autenticazione obbligatoria.

Le verifiche effettuate confermano che avviando il servizio con il binding all’indirizzo 0.0.0.0 senza autenticazione, è possibile stabilire una connessione senza credenziali e invocare command/exec, ottenendo l’esecuzione reale dei comandi richiesti con restituzione dell’output.

Nella configurazione testata non è stato necessario abilitare modalità particolari o disattivare esplicitamente il sandboxing. Il comportamento osservato deriva dalla configurazione di default/attiva del server che ha consentito l’esecuzione di comandi arbitrari, inclusi strumenti come nmap già presenti sul server.

Il problema non è quindi l’esistenza di command/exec, ma il fatto che una API con capacità di controllo diretto e completo sul sistema possa essere esposta in rete tramite una configurazione supportata, senza alcun vincolo tecnico che ne impedisca l’avvio in assenza di protezioni.

Conclusioni

In questa configurazione, l’app-server può diventare un punto di accesso remoto con capacità di esecuzione comandi. Il rischio non deriva da un exploit tradizionale, ma dall’esposizione di un canale di comunicazione privilegiato senza autenticazione obbligatoria e senza valori di default sicuri.

L’esposizione non autenticata del servizio in rete deve quindi essere considerata una configurazione ad alto rischio e non coerente con un utilizzo sicuro del componente.

È necessario limitare strettamente l’uso a contesti locali o fidati, evitare il binding su interfacce pubbliche, utilizzare canali protetti per accessi remoti e abilitare sempre l’autenticazione (--ws-auth) quando il servizio è esposto in rete.

Dal punto di vista del prodotto, sarebbe auspicabile l’introduzione di meccanismi di hardening che impediscano l’avvio di listener non locali in assenza di autenticazione.