Descubierta una vulnerabilidad que podría permitir dejar sin servicio a la mayoría de servicios web

 Vulnerabilidad que afecta a la gran mayoría de las plataformas de servicios web actuales y que podría permitir la realización de ataques de denegación de servicio.

La vulnerabilidad fue presentada por dos investigadores en una conferencia en el ya mítico congreso Chaos Communication Congress, organizado por el Chaos Computer Club. La conferencia completa se puede ver en YouTube en:
http://www.youtube.com/watch?v=R2Cq3CLI6H8

El problema afecta a una larga lista de tecnologías de desarrollo web, incluyendo PHP, ASP.NET, Java, Python, Ruby, Apache Tomcat, Apache Geronimo, Jetty o Glassfish. Concretamente versiones:

* Microsoft .NET Framework 1.x, 2.x, 3.x, y 4.x (CVE-2011-3414)
* PHP 5.3.x (CVE-2011-4885)
* Ruby 1.8.x (CVE-2011-4815)
* Rubinius 1.x
* Rack 1.x (CVE-2011-5036)
* Oracle GlassFish Server 3.x (CVE-2011-5035)
* Apache Tomcat 5.x, 6.x, y 7.x (CVE-2011-4084)
* Apache Geronimo 2.x (CVE-2011-5034)
* Google V8 (CVE-2011-5037)
* Jetty 6.x, y 7.x (CVE-2011-4461)
* Plone 4.x (CVE-2011-4462)
* JRuby 1.x (CVE-2011-4838)

Básicamente es más fácil decir a los lenguajes que no afecta: Perl y CRuby 1.9.

La base de la vulnerabilidad reside en que prácticamente todos los lenguajes almacenan en tablas hash los valores de los parámetros de las peticiones web. Pero las funciones hash empleadas se ven afectadas por colisiones. Por lo que es fácil generar peticiones con parámetros que tengan el mismo hash. De forma que cuando el servidor inserta los valores en la tabla hash se ve obligado a realizar un gran número de operaciones. Lo que, con un número adecuado de parámetros, provoca la denegación de servicio.

Este problema no es nuevo, básicamente es idéntico a otro ya conocido desde 2003, que afectaba a Perl. Motivo por el que este lenguaje ya incorpora la adecuada solución, que pasa por aleatorizar la clave empleada para calcular el hash. De esta forma, el atacante no podrá precalcular parámetros con hashes que provoquen colisiones. Otra forma de evitar el fallo, mucho más sencilla, pasa por limitar el número de parámetros procesados en cada petición.

Para tener una idea del alcance problema, en un sistema con Intel Core i7 sobre una aplicación PHP, bastarían 500k de datos POST para ocupar un minuto de tiempo de cálculo de CPU. De tal forma que bastaría con una conexión de entre 70 a 100 kbits/s para mantener ocupada una CPU de este tipo.

Los principales lenguajes ya han publicado actualizaciones y parches que corrigen esta vulnerabilidad, que pueden ser descargadas desde la página oficial de cada uno de ellos.

Microsoft, por ejemplo, ha publicado un boletín de urgencia para corregir esta vulnerabilidad en Microsoft .NET Framework (si bien este problema no es considerado crítico), y además solucionar otras tres vulnerabilidades (una de ellas crítica).

Apache Tomcat ha implementado una contramedida para evitar los efectos de un posible ataque, para lo que proporciona la nueva opción “maxParameterCount” que limita el número de parámetros procesados en cada petición. Por defecto está fijado a 10.000, suficientemente alto para soportar cualquier aplicación y suficientemente bajo para mitigar los efectos del DoS. Esta contramedida está disponible en las ramas 7.0.23 (en adelante) y 6.0.35 (en adelante).

En PHP una contramedida pasa por limitar el tiempo de CPU de generación de una respuesta mediante “max_input_time”

Otras actualizaciones:
* Ruby: actualización a la versión 1.8.7-p357.
* PHP 5: corregido a través de repositorios SVN.
* Rack: corregido a través de repositorio GIT.
* Apache Tomcat: actualización a las versiones 5.5.35, 6.0.35, y 7.0.23.
* JRuby: actualización a la versión 1.6.5.1.
 Fuente