Una vulnerabilidad que afecta a la gran mayoría de las plataformas de servicios web actuales 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:
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.
Más información:
#2011-003 multiple implementations denial-of-service via hash algorithm collision
Efficient Denial of ServiceAttacks on Web ApplicationPlatforms
Microsoft Security Bulletin MS11-100 – Critical
Vulnerabilities in .NET Framework Could Allow Elevation of Privilege (2638420)
[SECURITY] Apache Tomcat and the hashtable collision DoS vulnerability
Denial of Service through hash tablemulti-collisions
Denial of Service via Algorithmic Complexity Attacks
CCC Event blog – 28C3
Antonio Ropero
Twitter: @aropero
Muy poco rigor en este artículo. Agrupar bajo el epígrafe “servicios web” a .NET, glassfish, PHP, Tomcat, Geronimo, JRuby, etc. es, cuando menos, confuso. Unos son servidores web; otros, servidores de aplicaciones; otros, lenguajes de programación… y NINGUNO de ellos tiene que ver realmente con “servicios web” (“web services”, para entendernos). ¿No hubiera sido más sencillo y preciso hablar de “tecnologías web”?
Adicionalmente habla de vulnerabilidad en java pero no hay detalle por ninguna parte en el artículo