EDICIóN GENERAL
276 meneos
 

Error de seguridad en wordpress permite tirar servidores en apenas 5 minutos

El error que afecta a todas las versiones ha sido comunicado a security@wordpress.org sin que hayan publicado ningún parche oficial. En el propio articulo donde se detallan los puntos del grave agujero de seguridad, aparte de un código de ejemplo para explotar el mencionado bug, se incluye un parche para solucionar el problema en caso de que tu Wordpress esté afectado.

| etiquetas: wordpress , seguridad , error , bug , servers , caidos
143 133 0 K 587 mnm
143 133 0 K 587 mnm
Si quieres extenderlo a "todas los softwares PHP que no sanean mb_convert_encoding()" es válido tambien... :-)
#1 depende de muchos factores, sobretodo de si se puede o no controlar el tercer argumento. Esto en realidad sucede con muchas funciones de PHP, pero precisamente mbstring tiene funciones, como esta, que consumen muchísimo, y que el usuario pueda alterar su input, es peligroso.

Lo raro, es que se hace poco estudio sobre ataques de consumo y agotamiento de recursos en webapps, mientras que es motivo de extenso estudio en otras capas, como en los servidores de servicios de red.
Un poco desagradecidos los señores de Wordpress. Alguien se preocupa de revisar el código y mandar una solución válida y ellos lo desprecian y no contentos con eso implementan una solución que sigue teniendo fallos. En fin, ellos son los que pierden.
#0 debería usar resaltado de sintaxis en el blog, el post está un poco ilegible.
#5
RTFA:

> Por lo que si en $charset (mediante $_POST) le enviamos una cadena con 350k de UTF-8 separados por comas, y en $title por ejemplo, le enviamos una cadena de 350k de largo, hará comprobaciones sobre 350k^2 caracteres, lo cual requiere realmente mucho tiempo (minutos).
#7 menudo script-kiddie...

Sobre la noticia, aunque sirve para hacer un DoS, depende tambien de como esté configurado el php, ya que mediante el php.ini se puede limitar el uso de cpu y duración de ejecución de cada script.

Por otro lado, usando el modulo mod-security de apache se suelen restringir el tamaño de los mensajes POST que puede recibir un servidor, al final no es tan facil como parece...
#11 y #12

Yo pensaba igual, es una buen observación, conozco la directiva max execution time de php, y la función set_time_limit, de hecho, la conozco por que programando me ha saltado en mas de una ocasión.

De hecho, esa directiva es el motivo de por que no envío mas de 350k's, por que se que aunque si enviase 1mb por post, tardaría el triple, no importa, por que con 350k's ya se llega a los 30 segundos que tiene por defecto php de máximo tiempo de ejecución.

Sin embargo, el problema…   » ver todo el comentario
me parece muy mal que publiques el fallo sin que halla un parche oficial.

Por mucho que los de wordpress no te hagan caso a la primera. Deberias seguir intetandolo y no publicar tu descubrimiento hasta un tiempo despues de que las actualizaciones buenas hayan salido.
#8 si, insistiendo hasta el infinito, y todo eso con mi tiempo, por que no olvides que esto es software libre, y la gente que encuentra esos errores es voluntaria y todo eso.

Encima de puta, hay que poner la cama, como decía mi abuela.
#9 ¿Qué pasa que tu abuela la gran P no cobraba un suplemento por la cama? Seguro que si hombre :-D
#8 ¿Te parece mal que publique el fallo (con parche incluido para solucionar el problema) cuando los de WordPress no lo han solucionado y cualquier otra persona podría estar utilizando el fallo con fines maliciosos?

El fallo es de cajón. Si no lo ha encontrado otra persona antes (que lo dudo), seguro que otra lo encontrará tarde o temprano... es mejor que alguien haya publicado el parche para que podamos prevenirlo.
PHP suele tener por defecto un límite de tiempo de ejecución de 30 o 60s, además un límite de memoria de unos 64MB por script (según servidor). Mientras se está ejecutando una petición de estas se pueden seguir ejecutando otras sin problemas. Eso sí, si se abren varias peticiones la vez y el servidor no tiene ningún límite de peticiones simultáneas por IP pues sí que se puede dejar KO el servicio durante un rato, aunque no debería afectar al funcionamiento de otros servicios como el SSH, el MySQL o el FTP.
Estoy probando el exploit con mi web para ver si le afecta pero al ejecutarlo salen errores:

Parse error: syntax error, unexpected T_STRING, expecting ',' or ';' in exploit.php on line 6
#14 Lo mismo por acá. Lástima no saber PHP.
#14 #16 el error es porque al copiar y pegar de la web las comillas y apostrofes salen diferentes y no funciona bien.

He copiado el codigo que funciona en la siguiente URL

pastebin.com/f5bdff8f
Parse error: syntax error, unexpected T_STRING, expecting ',' or ';' in exploit.php on line 6

prueba a canviar las comillas

echo “You need to specify a url to attackn”;

echo "You need to specify a url to attackn";
#16 Perdona pero será caMBiar las comillas, ¿no?

Lo siento, pero es que me ha dañado los ojos.
Chapó el autor del POST...
hombre .. me parece mucho peor que wordpress lo ignore de esa manera... quizas publicando el error se den prisa a corregirlo oficialmente desde wordpress...
y otro FAIL mas para php.
#22 la culpa no es de php es de los programadores.
#23 fail para php? eso es como decir cuando te casa windows "otro fail más para C"
#23, #27: a ver, lamers

la culpa es totalmente de php, es un fallo de diseño que una funcion del core necesite validacion extra para no petar (por lo menos, ya que los programadores de php son tan noobs, que lo especifiquen en la documentacion)

y otro mas porque php tiene una laaarga historia de malas configuraciones por defecto y fallos de diseño (no se, ahora que me vengan a la cabeza... register globals on, safe mode off, no escapar automaticamente la url... una mala configuracion por defecto es fallo del lenguaje...)

y nenes, se de lo que hablo, soy contrib en un interpretador que corre bajo la VM de java y que NO hace estas cosas mal.
cierto, es lo que tiene pensar en catalan y escribir en castellano que uno termina usando un poco de todo , sorry.
El fin de internet esta cerca :-)
Con todas las paginas de p2p que hay en wordpress la sgae ya esta usando el script, seguro.
Al final si que han sacado una nueva versión:

wordpress.org/development/2009/10/wordpress-2-8-5-hardening-release/

The headline changes in this release are:

* A fix for the Trackback Denial-of-Service attack that is currently being seen.
* Removal of areas within the code where php code in variables was evaluated.
* Switched the file upload functionality to be whitelisted for all users including Admins.
* Retiring of the two importers of Tag data from old plugins.
#30 ¿Ese fix del trackback en la 2.8.5 se supone que soluciona el fallo?
Otra pregunta, ¿si el servidor tiene un límite para el tiempo de ejecución de 4 horas estoy a salvo?
comentarios cerrados

menéame