La vulnerabilità di PHP può arrestare milioni di server - max_input_vars!

5

La versione recente di PHP 5.3.9 è stata rilasciata un paio di giorni fa e Hash Collisions sono stati risolti, la maggior parte dei server in realtà non ha aggiornato il suo server fino ad ora, compreso il server del mio sito web .
In questo articolo mi sono imbattuto in una parte a cui è stato detto che i siti che si trovano in un hosting condiviso non possono aggiornare il loro PHP da soli, lo so, ma mi chiedo se non sia possibile usare ini_set per impostare max_input_vars per proteggere il tuo sito (non il server)?
So che se qualcuno attacca il server, l'intero sito sarà disattivato, ma impostando il max_input_vars almeno il mio sito sarà sicuro se qualcuno attacca il mio sito. È corretto?

    
posta ALH 13.01.2012 - 14:13
fonte

2 risposte

2

Interessante articolo (CVE-2011-4885 per coloro a cui piacciono i riferimenti), grazie per l'heads-up - leggerò su questo punto ma alcuni punti risaltano già.

  • solo per chiarire - il problema è all'interno del livello logico - non del server web stesso.
  • la tua domanda se è possibile utilizzare ini_set è basata sul fatto che il motore PHP sottostante sia stato aggiornato - quando hai già affermato che è improbabile che ciò accada per molti provider di hosting. OTOH qualsiasi provider di hosting che aggiorna il proprio PHP probabilmente distribuirà le relative modifiche ini o fornirà un meccanismo per farlo.
  • mentre la maggior parte delle società di hosting eviterà attivamente di imporre un aggiornamento importante ai propri utenti, dovrebbe implementare patch del fornitore per le distribuzioni esistenti - e questa patch è già stata sostituita a tutte le versioni di produzione di 5.3 e 5.2 , Credo che Redhat abbia ora rilasciato patch per l'attuale RHEL
  • ci sono almeno 4 diversi posti in cui le impostazioni di ini possono essere modificate in PHP - nel file php.ini, nella configurazione del webserver (quando PHP è implementato come modulo), nei file .htaccess (di nuovo se il modulo) e in il codice PHP stesso - ma non tutte le impostazioni possono essere modificate in tutte le posizioni: finora la nuova configurazione var non è nel manuale per dire dove può essere modificata.
  • per sfruttare questa vulnerabilità, sarebbe necessario inviare una quantità significativa di variabili nella richiesta - Apache (e probabilmente la maggior parte degli altri server Web) consente un certo controllo sulla dimensione totale della richiesta, del corpo della richiesta e dei dati POST - anche il tempo di esecuzione - l'uso efficace e selettivo di queste opzioni di configurazione sia nella configurazione httpd che in specifici alberi di directory usando .htaccess potrebbe essere usato per mitigare qualsiasi potenziale attacco - tenendo presente qualsiasi necessità di supportare (es.) upload di file.
  • la natura di un DOS basato su questa vulnerabilità è, in effetti, molto simile al problema con le richieste di intervallo su Apache (CVE-2011-3192) - sebbene una grave vulnerabilità, non ho visto molte prove di tale difetto ampiamente sfruttato.

I know that if someone attacks to the server the whole site will be down, but by setting the max_input_vars at least my site will be safe if somebody attack my site

Non capisco - sicuramente un attacco basato su questa vulnerabilità non produrrà perdite o modifiche di dati / codice (AFAICS).

    
risposta data 13.01.2012 - 16:40
fonte
2

I know that if someone attacks to the server the whole site will be down, but by setting the max_input_vars at least my site will be safe if somebody attack my site. Is this correct?

Direi che, a meno che max_input_vars sia inferiore al valore predefinito (1000), possa ancora accadere con più richieste, vorresti impostarlo al numero massimo di vars che il tuo software utilizza, ma che dolore per scoprire (o impossibile se hai campi dinamici).

IMO: cerotto su un cancro, hanno bisogno di cambiare l'algoritmo hash in modo casuale.

    
risposta data 13.01.2012 - 17:39
fonte

Leggi altre domande sui tag