La patch PHP2Shell è l'unica correzione affidabile per le vulnerabilità PHP
PHP2Shell comprende due vulnerabilità critiche di remote code execution (RCE) in PHP, ovvero debolezze che potrebbero consentire a un aggressore di eseguire da remoto comandi su un web server vulnerabile. PHP assegna a entrambe le vulnerabilità un punteggio di 9,2 su 10 e ha programmato le correzioni per le 14:00 UTC del 21 ottobre. Al momento del periodo di riferimento, tali correzioni non erano ancora state rilasciate e PHP non aveva comunicato le versioni interessate, il componente vulnerabile o alcun workaround basato sulla configurazione.
Questa mancanza di dettagli tecnici significa che gli amministratori non possono ancora dimostrare che una particolare impostazione difensiva blocchi PHP2Shell. Cloudflare ha segnalato i primi tentativi di exploit e ha distribuito regole di filtraggio di emergenza, anche per il proprio piano gratuito, ma ha descritto tali regole come una protezione temporanea in attesa che sia possibile applicare le patch ai sistemi. Non era stata confermata alcuna compromissione riuscita, non era stato dimostrato che il codice exploit pubblico in circolazione funzionasse e nessuna delle due vulnerabilità figurava nel catalogo delle vulnerabilità note come sfruttate della US Cybersecurity and Infrastructure Security Agency al momento della verifica, il 21 ottobre. Separatamente, watchTowr ha dichiarato di aver riprodotto una delle vulnerabilità, ma di non aver rilevato attacchi.
La mitigazione proposta più diffusamente è session.upload_progress.enabled=0, che disabilita la funzionalità Session Upload Progress di PHP. Questa funzionalità è abilitata per impostazione predefinita e registra l'avanzamento di un caricamento di file, in modo che un'altra richiesta possa verificarlo. GMO Flatt Security aveva inizialmente suggerito che disabilitarla potesse essere utile, avvertendo tuttavia di non poter confermare una protezione completa. In un aggiornamento con timestamp delle 14:00, ora del Giappone, ossia le 05:00 UTC, l'azienda ha chiarito che la sola impostazione non era sufficiente e ha affermato che ci si aspettava che gli aggressori fossero in grado di aggirarla. Anche alcuni membri del progetto PHP hanno dichiarato che la modifica delle impostazioni di configurazione INI non può sostituire l'applicazione di patch o l'upgrade di PHP.
Inoltre, non vi è alcuna conferma pubblica che una delle due vulnerabilità risieda in Session Upload Progress. GMO Flatt Security ha collegato il proprio consiglio alla sua valutazione di ciò che PHP2Shell potrebbe comportare. Un audit anonimo del codice ha contestato la vulnerabilità attribuita a questa funzionalità e ha affermato che il proof-of-concept in circolazione non funzionava contro le versioni PHP rilasciate. Upwind ha continuato a indicare l'impostazione come mitigazione immediata sulla base dell'analisi di un altro ricercatore, mentre watchTowr ha dichiarato che non esisteva alcun workaround confermato. Saranno necessari l'advisory finale di PHP e le modifiche al codice per risolvere il disaccordo.
Gli amministratori che hanno già disabilitato upload progress non devono annullare la modifica, ma non dovrebbero considerarla una correzione di sicurezza. Il manuale di PHP raccomanda già di disabilitare la funzionalità quando un'applicazione non necessita di barre di avanzamento dei caricamenti, poiché i nomi memorizzati dei file e dei campi dei form non vengono convalidati e possono contenere codice PHP. Disabilitarla su un sito che richiede questa funzionalità impedirà il funzionamento delle barre di avanzamento dei caricamenti.
L'impostazione deve inoltre essere modificata nel processo PHP che gestisce effettivamente le richieste del sito web. È un'opzione INI_PERDIR e può essere configurata tramite php.ini, .htaccess o .user.ini. Il metodo .user.ini si applica solo ai deployment CGI e FastCGI, non al modulo Apache, e per impostazione predefinita PHP controlla tale file ogni 300 secondi, quindi una modifica può richiedere cinque minuti prima di diventare attiva. I siti che utilizzano il modulo Apache devono ricorrere a .htaccess o alla configurazione del server. Controllare php -i da una riga di comando non conferma il valore utilizzato da PHP-FPM o mod_php per il traffico web.
Gli amministratori in grado di aggiornare rapidamente dovrebbero preparare prima del rilascio la procedura di deployment, le verifiche successive all'aggiornamento, le approvazioni ed eventuali riavvii necessari. Il componente da aggiornare è il runtime PHP che gestisce le richieste web, come PHP-FPM, mod_php o CGI, anziché WordPress, Laravel o un'altra applicazione eseguita al di sopra di esso. PHP fornisce attualmente correzioni per quattro branch supportati, dalla versione 8.2 alla 8.5. Le release corrette precise e l'intero intervallo delle versioni interessate avrebbero dovuto essere pubblicati insieme all'advisory.
I siti che non possono applicare immediatamente la patch dovrebbero ridurre la propria esposizione. CERT-EU consiglia di valutare l'isolamento delle applicazioni esposte a Internet dalle reti pubbliche fino alla disponibilità di una correzione. Tra le opzioni pratiche vi sono la disattivazione temporanea di un sito o il suo posizionamento dietro un accesso autenticato, una VPN o un'allowlist di client approvati. Gli amministratori devono inoltre impedire ai visitatori di aggirare questi controlli e raggiungere direttamente l'origin server. GMO Flatt Security raccomanda inoltre di ridurre i dati archiviati e i privilegi del server, rimuovere le credenziali salvate e i ruoli cloud e conservare i log in una posizione sicura per indagini successive.
I branch PHP non supportati precedenti alla versione 8.2, inclusi 8.1, 7.x e 5.x, non ricevono correzioni direttamente da PHP. Questi sistemi richiedono un upgrade, l'isolamento o la rimozione da Internet, anche se una distribuzione Linux o un provider di hosting potrebbe pubblicare un backport, che applica una correzione di sicurezza senza passare a una nuova versione principale. CloudLinux ha dichiarato che i propri pacchetti dipendevano dalla pubblicazione della release upstream da parte di PHP e che sarebbero seguiti una volta pronti.
Un'altra misura temporanea proposta consiste nel rifiutare, a livello di web server e prima che PHP le elabori, le richieste contenenti un body multipart/form-data. Questa misura prende di mira il formato di richiesta sospettato di essere coinvolto nelle vulnerabilità, ma rimane non confermata. Bloccare soltanto le richieste POST è insufficiente, perché PHP 8.4 ha introdotto request_parse_body(), che può elaborare body multipart inviati con altri metodi. Un blocco più ampio interromperà i caricamenti di file e i form che utilizzano dati multipart anche quando non è allegato alcun file.
Un web application firewall può filtrare i pattern noti delle richieste malevole, ma non sostituisce la patch PHP2Shell. Le regole di Cloudflare esaminano soltanto le richieste instradate attraverso il suo servizio, non possono proteggere un origin server che rimane direttamente raggiungibile e potrebbero non rilevare nuovi percorsi di attacco. Per i proprietari di siti WordPress che stanno valutando le proprie soluzioni di hosting, AEU Hosting offre hosting WordPress gestito, protetto end-to-end.
I clienti di servizi di hosting gestito e condiviso dovrebbero chiedere al proprio provider quando verrà installato il pacchetto PHP corretto. Distribuzioni Linux come Debian e Ubuntu potrebbero mantenere una versione PHP apparentemente obsoleta pur applicando la correzione tramite backport, pertanto la sola stringa di versione visibile potrebbe non essere sufficiente a stabilire se un server è protetto. Gli amministratori dovrebbero confrontare la versione completa del pacchetto con l'advisory della distribuzione oppure esaminarne il changelog. Dopo l'aggiornamento, dovrebbero verificare tramite php.net o gli advisory di sicurezza GitHub di PHP la release corretta per il proprio branch, controllare quali versioni PHP identifica come interessate ed esaminare i log alla ricerca di attività sospette avvenute prima dell'applicazione della patch.