Portada
mis comunidades
otras secciones
#2:
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.
#10:
#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.
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.
#15:
#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 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í.
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í.
#11:
#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...
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...
Comentarios
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.
#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...
En realidad... un servidor bien configurado, con límites de uso de memoria, cpu y tiempo de proceso, no seria tan tan fácil de tumbar. En todo caso podria perjudicar el rendimiento.
#8 Mientras publique un parche, yo se la dejaría pasar.
#11 También está suhosin para php en sí.
#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 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í.
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.
#0 debería usar resaltado de sintaxis en el blog, el post está un poco ilegible.
Chapó el autor del POST...
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:
http://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?
hombre .. me parece mucho peor que wordpress lo ignore de esa manera... quizas publicando el error se den prisa a corregirlo oficialmente desde wordpress...
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.
El fin de internet esta cerca
cierto, es lo que tiene pensar en catalan y escribir en castellano que uno termina usando un poco de todo , sorry.
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
http://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.
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
#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.
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.
Guau. Se cae Internet.Servicios importantisimos están amenazados.
Wordpress.Los bloggers! ¿que vamos a hacer sin ellos?
p.d. ¿de donde dices que se puede descargar el exploit?
#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).
#6 muy bien, ahora falta que alguien lo pruebe contra algun objetivo que merezca la pena ...si hay alguno.