rooibo.wordpress.com/2009/10/17/agujero-de-seguridad-en-w... por
Mike_Litoris el 17-10-2009 16:17 UTC publicado: 17-10-2009 20:25 UTC
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 negativos:
0 usuarios:
143 anónimos:
133
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.
Wordpress.Los bloggers! ¿que vamos a hacer sin ellos?
p.d. ¿de donde dices que se puede descargar el exploit?
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).
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.
Encima de puta, hay que poner la cama, como decía mi abuela.
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.
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...
Parse error: syntax error, unexpected T_STRING, expecting ',' or ';' in exploit.php on line 6
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 reside en que tu puedes hacer una petición cada 5 segundos mas o menos (por el peso de la petición) y se tardan 30segundos en ser procesadas. Por lo que en poco tiempo, el servidor tiene una cola de cientos para procesar, y cada una, consume la CPU casi completamente.
Acerca del limite de memoria de PHP (memory_limit en php.ini) algo que he descubierto haciendo pruebas con este bug contra mi propia servidor (en casa) es que memory_limit no se aplica para módulos de php como mbstring, o al menos no en instalación, habría que ver los detalles, por que yo tenía hilos de apache consumiendo 200mb de ram, cuando tengo memory limit a 16mb, sería un fallo bastante grande php no limitar la memoría de los plugins, sólo la del script, y es lo que parece.
Cómo digo, lo he probado bastante, y no resulta tan fácil prevenirlo, aparte de que la solucíón que proponen por ejemplo de modificar el tamaño de $_POST, afecta globalmente a todo el wordpress, pudiendo hacer que otras cosas dejen de funcionar, por que necesiten $_POST mas grandes.
350k por post no es tan exagerado, de hecho, cuando haces post de un archivo (upload) es fácil que superes eso.
Aparte de eso, evidentemente que si se ponen grandes medidas de seguridad en el servidor se pueden paliar los efectos (aunque no detenerlos completamente) pero hay efectos secundarios muy complejos, por ejemplo, los hilos en ejecución conectan al mysql, y hay un limite de conexiones a mysql por host, por lo que si se le acumulan a apache muchas request en proceso (por que tienes limitada la CPU) y todas conectadas al mysql, la siguiente request no podrá conectar al mysql, con el consecuente fallo.
Cómo digo, se pueden paliar los efectos con trabajo en el servidor, pero el bug sigue ahí, la solución es que arreglen wordpress.
#14 a mi me funciona, vigila que le comentario que hay en las primeras líneas no se haya partido en dos líneas o alguna cosa así.
prueba a canviar las comillas
echo “You need to specify a url to attackn”;
echo "You need to specify a url to attackn";
Lo siento, pero es que me ha dañado los ojos.
He copiado el codigo que funciona en la siguiente URL
pastebin.com/f5bdff8f
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.
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.
Otra pregunta, ¿si el servidor tiene un límite para el tiempo de ejecución de 4 horas estoy a salvo?