Analisi del PoC php2shell: praticabile ma non facile da automatizzare

Per colpire con php2shell servono quattro richieste consecutive allo stesso worker PHP, più la conoscenza esatta della build in uso. È il motivo per cui, finora, non si vede sfruttamento di massa¹.

Il punto di partenza è un’analisi diretta dei proof of concept pubblicati. L’autore nota opinioni discordanti sulla gravità del bug, si incuriosisce, esamina i PoC e mette alla prova le condizioni necessarie per ottenere un risultato¹. La condizione chiave non cambia: le quattro richieste devono arrivare sul medesimo processo, senza rimescolamenti tra worker¹.

Il miglior PoC individuato è il repository 9bie/php2shell-bypass-aslr-exp. Esiste anche un fork con la documentazione tradotta in inglese. Entrambi mostrano in concreto quali vincoli vanno rispettati per arrivare all’esecuzione¹.

Il PoC prende un’immagine Docker che usa il numero di worker predefinito di mod_php, pari a 150. Poi apre 149 connessioni che inviano mezza richiesta per tenere occupati i 149 worker. Sul centocinquantesimo invia le quattro richieste di exploit¹. La sequenza è controllata. Il bersaglio è sempre lo stesso processo.

Questa messa in scena presuppone condizioni stabili. In produzione, anche un sito moderatamente popolare usa più macchine o container, ciascuno con più worker PHP, dietro un bilanciatore e con traffico bot continuo¹. Con questa topologia diventa complicato convogliare quattro richieste consecutive sullo stesso worker. Per riuscirci, bisogna provare una gamma ampia di numeri di connessioni da aprire¹.

C’è poi la compatibilità. L’exploit richiede di conoscere esattamente la build, cioè versione di PHP, versione del sistema operativo e architettura. In alternativa bisogna tentare varianti per ogni build possibile¹. Anche questo aggiunge vincoli pratici.

La combinazione di questi due fattori, orchestrazione dei worker e specificità della build, aiuta a spiegare perché non si osservano ondate automatiche di compromissioni. Il PoC funziona, ma richiede un controllo stretto dell’ambiente di esecuzione che i target reali non offrono facilmente¹.

L’autore precisa di non essere uno sviluppatore di exploit e invita a prendere l’analisi con cautela, perché potrebbero esistere altri fattori. Aggiunge una nota di umiltà: se lo sfruttamento di massa partisse proprio alla pubblicazione, se ne assumerebbe l’errore di valutazione¹.

I limiti emergono dai dettagli operativi descritti. La prova usa un’immagine Docker e un assetto noto di mod_php, con un numero fisso di worker. Le connessioni parziali servono a saturare i processi fino a isolarne uno, su cui lanciare la sequenza di quattro richieste. In un ambiente con più nodi, bilanciamento e traffico continuo, replicare lo stesso controllo risulta più difficile. L’idea centrale resta invariata: senza indirizzare quattro richieste consecutive allo stesso worker, e senza conoscere con precisione la build bersaglio, l’exploit non parte¹.

L’analisi non esclude evoluzioni. Indica però un punto fermo per chi valuta il rischio oggi: l’efficacia nel mondo reale dipende dal riuscire a riprodurre le stesse condizioni che il PoC impone in laboratorio¹.