Vulnerabilità PHP (e altri linguaggi)

Vulnerabilità PHP (e altri linguaggi) postato il 13/01/2012 11:24:45 nel forum programmazione, open source e hosting e modificato da blancks il 13/01/2012 11:33:21

Per i non anglofoni faccio un sunto dell'articolo, per chi volesse leggerlo per intero può trovarlo al seguente indirizzo.

http://www.phpclasses.org/blog/post/171-PHP-Vulnerability-May-Halt-Millions-of-Servers.html http://www.phpclasses.org/blog/post/171-PHP-Vulnerability-May-Halt-Millions-of-Servers.html ↗


PHP come altri linguaggi per il web pare soffrano di una vulnerabilità non poco problematica, la hash table collision.

In parole povere, senza approfondire le meccaniche di funzionamento interne di PHP, consiste in un overload della richiesta http da inviare al server di modo che vi sia una quantità impressionante di dati da mandare in pasto a PHP per lo smistamento nelle superglobali _POST, _GET, _COOKIE permettendo così ad un numero di richieste di molto inferiore a quelle necessarie per un DDoS di creare un singolo processo PHP sulla macchina che impiega il 99% della CPU rallentando il tutto fino ad un possibile arresto del sistema.

La vulnerabilità a quanto pare non è nuova e venne presentata la prima volta nel 2003 ma fu tenuta in considerazione (all'epoca) solo dai team di sviluppo di Perl e cruby, PHP e altri linguaggi odierni si trovano quindi a dover affrontare in sostanza il rimaneggiamento di un vecchio problema.

Perché il problema torna all'attenzione adesso ? PHP nel 2003 non era certamente diffuso come oggi (secondo i ricercatori, dice l'articolo, "77% of the Web servers run PHP").

I danni derivanti dal problema non sono stati del tutto risolti ma sono stati fortemente limitati grazie alle ultime patch applicate nelle release 5.3.9 RC5 e 5.4.0 RC5 di PHP, in sostanza è stato introdotto nel php.ini il valore max_input_vars, di default impostato a 1000, che indica il numero massimo di informazioni da catalogare negli array di sistema ignorando i successivi.

Più è impostato ad un valore basso meglio è, e visto che siamo in tema di gdr-online ritengo che impostarlo a non più di 100/150 (a seconda dell'applicazione) possa essere sufficiente.

Cosa succede se non si può eseguire l'upgrade di una vecchia versione di PHP a causa di una customizzazione che mi farebbe perdere del lavoro fatto ? Se sul vostro server dedicato o vps non potete effettuare l'upgrade di PHP per motivazioni varie potete ricorrere ad un utilissima estensione chiamata Suhosin sviluppata da Stefan Esser nel 2004, uno specialista in materia di sicurezza che già all'epoca non prese sottogamba la questione, e che prevede un parametro analogo a quello introdotto recentemente nel php.ini chiamato max_vars http://www.hardened-php.net/suhosin/configuration.html#suhosin.get.max_vars ↗.

Se siete su un servizio di hosting condiviso ovviamente voi non potete farci nulla in proposito, sta al provider procedere con l'upgrade se non si tutela già da se con soluzioni proprietarie (ad esempio, è pratica comune per gli hosting bloccare i siti da cui provengono richieste anomale e potenzialmente pericolose per il server).


Dovrebbe essere ovvio per uno sviluppatore tenersi informato e prendere con serietà ed urgenza simili problematiche di sicurezza, sfortunatamente (aggiunge l'articolo) non tutti i developers sono bene educati a tal fine e anche developer esperti possono talvolta lasciarsi sfuggire qualche questione: nessuno può essere a conoscenza di tutto.

Motivo (con cui concordo appieno :p) per cui mi è sembrato giusto diffondere e riassumere l'articolo ;-)

13/01/2012 14:28:20

Molto interessante! Un motivo in più per passare a sviluppare applicazioni web in python :-D

13/01/2012 15:00:02

vino_veritas ha scritto: Molto interessante! Un motivo in più per passare a sviluppare applicazioni web in python :-D

Come ho scritto, molti linguaggi per il web sono affetti, python incluso.


http://securitytracker.com/id/1026478 http://securitytracker.com/id/1026478 ↗
http://arstechnica.com/business/news/2011/12/huge-portions-of-web-vulnerable-to-hashing-denial-of-service-attack.ars http://arstechnica.com/business/news/2011/12/huge-portions-of-web-vulnerable-to-hashing-denial-of-service-attack.ars ↗

Nell'ultimo link in particolare si legge:
"the flaw affects a long list of technologies, including PHP, ASP.NET, Java, Python, Ruby, Apache Tomcat, Apache Geronimo, Jetty, and Glassfish, as well as Google's open source JavaScript engine V8."

14/01/2012 01:57:29

Uddea, non avevo letto anche di python!
Non si salva proprio nessuno?

14/01/2012 12:48:50

vino_veritas ha scritto: Uddea, non avevo letto anche di python!
Non si salva proprio nessuno?

ci toccherà cambiare lavoro ed evitare la disfatta completa :ninja:

comunque da quel che si legge il PERL dovrebbe andare bene.

15/01/2012 21:37:29

stesso problema su IIS e il framework .net (e figurati se lo evitavano di finirci in mezzo =P)

16/01/2012 15:22:33 e modificato da blancks il 16/01/2012 15:35:07

rhllor ha scritto: (e figurati se lo evitavano di finirci in mezzo =P)

Ovvio, è una delle costanti regolatrici di questo mondo. :-p



Aggiungo:

Ho trovato, vagando per il web, dei messaggi pubblici di una mailing list in cui si discute il problema esponendo una soluzione per apache mediante l'uso di una regola definita tramite il mod-security http://comments.gmane.org/gmane.comp.apache.mod-security.user/9096 ↗

SecRule &ARGS "@gt 1000" deny

Vi risparmio la fatica di verificare che non funziona con i cookie su apache 2.x, il quale necessita di un ulteriore eccezione:

SecRule &REQUEST_COOKIES_NAMES "@gt 1000" phase:1,t:none,block

Nelle mail presenti nella pagina precedentemente linkata ci sono tutti i dettagli del caso, il concetto in sostanza è simile a quello del max_input_vars introdotto da PHP.