Sommario

La Vulnerabilità

Composer può risolvere pacchetti da diversi sistemi di controllo versione. Per Perforce, il repository è identificato da un URL p4:// che codifica host, porta e utente/stream. Quando il driver Perforce di Composer costruisce la riga di comando p4 sottostante, i campi presi dall'URL controllato dall'attaccante non sono sufficientemente sanificati prima di essere passati a una shell.

Poiché l'autore del manifest controlla completamente l'URL del repository, un attaccante che riesca a far eseguire a una vittima composer update/composer install contro un composer.json malevolo (ad esempio, una dipendenza avvelenata, un repository ostile o un job CI che elabora file di progetto non fidati) può uscire dall'invocazione p4 prevista ed eseguire comandi OS arbitrari con i privilegi del processo Composer.

Questo appartiene alla stessa famiglia di storici problemi di iniezione di argomenti nei driver VCS di Composer, dove i valori di URL/branch/stream finiscono in comandi shell senza escaping. Composer 2.9.6 rafforza il driver Perforce in modo che il payload iniettato non venga più eseguito.

La descrizione autorevole del comportamento qui dimostrato è il codice sorgente della PoC stesso (CVE202640176Test.php); consultare l'avviso ufficiale e il changelog di Composer per i dettagli della correzione a monte.

Come Funziona la PoC

La PoC è una singola classe, CVE202640176Test, che esegue un esperimento controllato A/B (differenziale):

1. Preflight — interroga --version su entrambi i binari di Composer, quello affetto (2.9.5) e quello corretto (2.9.6), e si interrompe anticipatamente se uno dei due non può essere invocato.
2. Esecuzione affetta (2.9.5)
   • Crea una directory temporanea isolata sotto il percorso temporaneo di sistema.
   • Scrive un composer.json la cui sezione repositories contiene una voce perforce con un URL p4:// malevolo che trasporta un payload shell iniettato.
   • Esegue composer update in quella directory.
   • Valida il risultato.
3. Esecuzione corretta (2.9.6) — ripete esattamente gli stessi passaggi contro il binario patchato.
4. Ripristino — un blocco finally ripristina sempre il composer.json originale nella directory del progetto.
5. Verdetto — stampa PASS solo quando l'esecuzione affetta mostra l'effetto collaterale e l'esecuzione corretta no.

Validazione (cosa conta come "sfruttato")

Per ogni esecuzione, validateRun() controlla tre cose:

Un'esecuzione è "OK" solo quando tutti e tre passano. Il test complessivo passa quando l'esecuzione affetta è OK e quella corretta non lo è — la firma precisa di una vulnerabilità reale che è stata successivamente patchata.

Il Payload di Iniezione (Spiegato)

L'URL del repository malevolo è costruito in writeComposerJson():

Analizzandolo:

• p4://127.0.0.1:1666:attacker_user — un URL Perforce dall'aspetto ben formato (host, porta 1666, utente).
• ;touch <marcatore> && echo '<runId>' > <marcatore> — i comandi shell iniettati. Il ; iniziale termina il comando p4 previsto; touch crea il file marcatore, e echo '<runId>' > <marcatore> scrive l'ID di esecuzione univoco nel file in modo che la PoC possa confermare che il payload (e non un processo non correlato) ha prodotto il file.
• :client_test — testo finale per mantenere plausibile il resto dell'analisi dell'URL.

Sul driver affetto i metacaratteri della shell sono onorati e il file marcatore viene creato. Sul driver corretto il valore è opportunamente escaped/citato, quindi la stessa stringa viene trattata come dati inerti e nessun marcatore appare.

Nota: la PoC utilizza un ID di esecuzione univoco con timestamp e scrive il suo marcatore all'interno di una directory temporanea isolata, quindi il payload è benigno e si autopulisce piuttosto che essere distruttivo.

Requisiti

• PHP 7.4+ (sviluppato/testato con PHP 8.x CLI). La PoC stessa usa solo funzioni core — nessun pacchetto Composer richiesto per eseguire l'harness.
• Due binari Composer disponibili come PHAR:
  • Composer 2.9.5 (affetto)
  • Composer 2.9.6 (corretto)
• Un ambiente shell di tipo POSIX (exec() esegue cd … && php …). Progettato per Linux/macOS.
• Un composer.json base nella directory del progetto (viene letto all'avvio, copiato in ogni esecuzione temporanea e ripristinato dopo).

Generalmente non è necessario un server Perforce attivo: la vulnerabilità risiede nel modo in cui Composer costruisce la riga di comando p4, e il payload iniettato viene eseguito prima/intorno a qualsiasi connessione p4 reale. Composer potrebbe registrare un errore di connessione Perforce — ciò è previsto e non influisce sulla prova del file marcatore.

Setup

1. Clonare / posizionare la PoC in una directory di lavoro.

2. Fornire un composer.json nella stessa directory della PoC. Un minimo è sufficiente:

   root@kitploit:~

   {
     "name": "research/cve-2026-40176-poc",
     "description": "Manifest base per la PoC differenziale CVE-2026-40176",
     "require": {}
   }
   

3. Ottenere i due binari Composer e posizionarli dove la PoC li aspetta (valori predefiniti mostrati):

   root@kitploit:~

   /usr/local/bin/composer-2.9.5.phar   # affetto
   /usr/local/bin/composer-2.9.6.phar   # corretto
   

   È possibile scaricare versioni specifiche di Composer dall'archivio ufficiale, ad esempio:

   root@kitploit:~

   curl -Lo /usr/local/bin/composer-2.9.5.phar https://getcomposer.org/download/2.9.5/composer.phar
   curl -Lo /usr/local/bin/composer-2.9.6.phar https://getcomposer.org/download/2.9.6/composer.phar
   

   Se i percorsi differiscono, modificare i due argomenti del costruttore in fondo a CVE202640176Test.php.

Utilizzo

L'harness esegue entrambe le versioni di Composer a turno e stampa un verdetto finale. Il composer.json originale viene ripristinato automaticamente anche se un'esecuzione fallisce (il lavoro avviene in directory temporanee usa-e-getta).

Esecuzione in Docker (raccomandata)

Il repository include un laboratorio containerizzato che replica esattamente l'ambiente: un runtime PHP CLI più le due versioni di Composer fissate ai percorsi che la PoC si aspetta, completamente isolate in rete in fase di esecuzione.

Questo costruisce cve-2026-40176-lab:latest (scaricando Composer 2.9.5 e 2.9.6 e verificando ogni --version durante la build) e esegue il test differenziale all'interno di un contenitore non privilegiato e senza uscita in rete.

Cosa garantisce il laboratorio:

• Binari reali. Entrambe le versioni di Composer sono recuperate dall'archivio ufficiale e la versione viene verificata al momento della build — la build fallisce rumorosamente se una versione fissata non è disponibile.
• Isolamento. Il servizio poc viene eseguito su una rete bridge internal (nessuna uscita verso host/internet), con cap_drop: ALL e no-new-privileges. Il payload di iniezione rimane contenuto.
• Nessun setup dell'host. Non è necessario posizionare PHAR sull'host o modificare manualmente i percorsi.

Ripuntare le versioni (devono rimanere sincronizzate con i due percorsi del costruttore nella PoC) tramite build args:

Opzionale — server Perforce live. Un servizio p4d è disponibile sotto il profilo full-lab (docker compose --profile full-lab up). La prova basata su marker non ne ha bisogno; esiste per ricercatori che desiderano un endpoint p4:// live. Nota che il payload della PoC punta a 127.0.0.1:1666, quindi il routing attraverso un contenitore p4d separato richiede di puntare l'URL della PoC all'host p4d.

Stato di Riproduzione (osservato)

Risultato onesto: contro le versioni reali, pubblicate di Composer 2.9.5 e 2.9.6, la PoC attualmente non si attiva, e il laboratorio riporta INCONCLUSIVO / FALLITO.

Eseguire il Composer affetto (2.9.5) contro il manifest malevolo della PoC genera, all'interno di Composer, prima che qualsiasi comando p4/shell venga costruito:

PerforceDriver::initialize() legge $this->repoConfig['depot'] per prima cosa, ma la voce del repository della PoC fornisce solo type e url (nessuna chiave depot). Il driver si interrompe a quel punto, quindi il payload iniettato ;touch <marcatore> nell'URL non viene mai raggiunto e nessun marcatore viene creato. L'isolamento di rete non è la causa — lo stesso errore si verifica con uscita completa in rete.

Cosa significa:

• Il laboratorio Docker stesso è corretto ed esegue fedelmente l'harness differenziale contro i binari genuini affetti/corretti. L'esito INCONCLUSIVO è una proprietà del payload della PoC, non dell'ambiente.
• Per esercitare il percorso effettivo di costruzione del comando Perforce, la configurazione del repository della PoC avrebbe bisogno almeno di una chiave depot (e realisticamente di un endpoint p4d live sotto il profilo full-lab). Raffinare il payload fino a quel punto è sviluppo di exploit oltre "allestire il laboratorio" ed è intenzionalmente lasciato fuori ambito qui.

L'"Output Previsto" di seguito è il risultato inteso/idealizzato della PoC, mantenuto per riferimento; non è ciò che il payload attuale produce contro il driver reale.

Output Previsto

Una dimostrazione riuscita assomiglia approssimativamente a questo (percorsi e ID varieranno):

Un codice di uscita di Composer diverso da zero è normale — composer update alla fine non riesce a recuperare il pacchetto (fittizio). La prova è il file marcatore, non lo stato di uscita di Composer.

Interpretazione del Risultato

Cause comuni di un risultato inconclusivo:

• Il driver si interrompe in PerforceDriver.php:40 con Undefined array key "depot" — la configurazione del repository manca di una chiave depot, quindi Composer non raggiunge mai il percorso di costruzione del comando p4. Questo è ciò che accade con il payload attuale della PoC contro la versione reale 2.9.5/2.9.6 (vedi Stato di Riproduzione).
• I percorsi dei binari Composer sono sbagliati o i PHAR non sono effettivamente 2.9.5 / 2.9.6.
• La shell dell'host o la funzione PHP exec() è sandboxed/disabilitata.
• L'output di Composer non contiene la stringa letterale p4 (percorso del driver non raggiunto).

Struttura del Progetto

L'intera PoC è un file:

• __construct() — memorizza i due percorsi binari, crea un ID di esecuzione con timestamp, istantanea il composer.json originale.
• run() — orchestra il preflight, l'esecuzione affetta, l'esecuzione corretta, il ripristino e il verdetto.
• prepareTempDir() — crea una directory di lavoro isolata per ogni esecuzione.
• writeComposerJson() — costruisce il manifest malevolo con l'URL p4:// iniettato.
• runComposer() — esegue composer update (argomenti escaped con escapeshellarg()) e cattura output + codice di uscita.
• validateRun() — controlla versione, file marcatore e attività del driver Perforce.
• preflightVersion() — legge --version da un dato binario.

Note di Progettazione

• Isolamento e pulizia. Ogni esecuzione usa la propria directory temporanea; il composer.json originale viene ripristinato in un blocco finally indipendentemente dal risultato.
• Harness vs. escaping del payload. L'harness escape i propri argomenti shell con escapeshellarg() (così la PoC non si inietta accidentalmente nelle proprie chiamate exec()). La vulnerabilità vive un livello più in profondità — in come Composer stesso costruisce il comando p4 — che è esattamente ciò che il payload prende di mira.
• Prova differenziale. Eseguire entrambi i binari (vulnerabile e patchato) in un unico passaggio rimuove l'ambiguità: lo stesso input produce comportamenti divergenti, che è una prova molto più forte di una singola osservazione positiva.
• Payload benigno. I comandi iniettati fanno solo touch/echo in un marcatore temporaneo univoco, rendendo la PoC sicura da eseguire ripetutamente senza effetti collaterali sull'host.

Limitazioni e Problemi Noti

• Percorsi binari hard-coded. I due percorsi PHAR sono passati in linea in fondo al file. Modificarli per il proprio ambiente (o rifattorizzare per leggere da argomenti CLI / variabili d'ambiente).
• Assunzione POSIX. Il pattern exec("cd … && php …") e il payload ;/&& presuppongono una shell simile a Unix; Windows non è supportato così com'è.
• Race condition / permessi di mkdir. Le directory temporanee sono create con modalità 0777; stringere se eseguite in un ambiente condiviso.
• Rilevamento versione basato su regex. Analizza Composer X.Y.Z dall'output; banner di Composer insoliti potrebbero impedire la corrispondenza.

Uso Responsabile

Questo repository esiste per comprendere e difendersi da CVE-2026-40176.

• Eseguirlo solo su sistemi e installazioni di Composer di cui si è proprietari o per i quali si è esplicitamente autorizzati a testare.
• Il messaggio per i difensori: aggiornare Composer a 2.9.6 o successivo, e non eseguire mai composer install/update su file composer.json non fidati (ad esempio, in pipeline CI che elaborano codice sorgente di terze parti) senza isolamento.
• Non utilizzare la tecnica di iniezione contro sistemi che non si controllano. Lo sfruttamento non autorizzato è illegale e non etico.

Riferimenti

• Composer — progetto ufficiale
• Archivio delle release di Composer (per scaricare PHAR specifici 2.9.5 / 2.9.6)
• Avviso ufficiale CVE-2026-40176 e changelog di Composer 2.9.6 (consultare il tracker di sicurezza della propria distribuzione / il Database Advisory di GitHub per i dettagli della correzione autorevole)
• Background sull'iniezione di argomenti nei driver VCS di Composer (la stessa classe di vulnerabilità), ad es. CVE-2021-29472

Autore: Ikarolaborda · PoC datata 2026-06-10.