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í.
Nada nuevo, los botones de "abuso" de los servidores de datos siempre han existido, no es un "sistema nuevo" que haya inventado un "hacker" (sic)
Eso si, me parece correcto que vendan el servico de buscar los contenidos del cliente y tramitar su retirada, para que este no tenga que ir pateandose internet cada dia. #26 ¿Ilegal? ¿el que? ¿Avisar a un servidor que hay un archivo cuyo propietario no quiere que este allí y pedir que lo quiten?
#44 Me parece una comprobación en base de datos tan sencilla que a menos que no quieran gastar ni un duro en máquinas no creo que perjudique prácticamente en nada. supongo además que para gestionar el contenido estático tendrán diferentes máquinas de "frontend" que consumirán poca CPU y que pueden usar para leer de la base de datos de forma distribuida. Eso sí, seguro que es mucho más complicado de montar que una cuenta atrás en javascript.
#20 El proceso se está llevando de forma muy opaca y nos enteramos de todo a última hora, a través de terceros, etc. Por eso las convocatorias para actuar están saliendo todas tarde...
en lo que respecta a la noticia, quizas si que fue un tanto excesivo, pero estoy de acuerdo de que aqui deberiamos tener derecho a defendernos mejor de ladrones y asaltantes, que vaya vergüenza de ley que protege más al criminal que a las víctimas...
#39 Tambien he oido que si dices tres veces tu nombre delante el espejo, sale una mano y te saluda...
#41 Con todos mis respetos a los tecnicos de motos, pero el mecanico de motos aunque tenga dos piernas y dos manos, no tiene la variedad de sistemas que tiene un coche. Si quieres te nombro algunos, pero creo que no hara falta
#40 En el concesionario donde trabajo, los extranjeros aprovechan que estan de vaciones para dejar el coche en nuestro taller, y no te lo pierdas, lo hacen año tras año. Ojo, no lo hacen por que seamos buenos, lo hacen porque la mano de obra es mas barata que en sus paises de origen, pero volver, vuelven, asi que no seremos tan malos
#62 No lo han parcheado en 10min, se publicó la noticia de su existencia 10min antes de publicar el parche.
#64 Que hayan publicado la noticia del bug diez minutos antes que el parche no significa que nadie lo conociese.
Además, ahora vamos a hablar de windows porque el otro SO sería mac: por todos es bien sabido que Microsoft lejos de hacer público un fallo y el cómo explotarlo, lo esconde hasta que tiene el parche, son otras personas quienes hacen públicos los agujeros y como explotarlos. El señor que descubrió este bug, antes de hacerlo público estuvo esperando a que los responsables hiciesen el parche. ¿Qué culpa tiene Microsoft (U otro S.O.) de que terceros hagan públicos los bugs en vez de esperar como hizo este señor? porque aquí esperaron que no lo corrigieron en 10min, eso es imposible directamente.
A veces leyendo algunos comentarios me da la sensación de que si llegan a publicar el parche 10min antes que la noticia que hace público el bug aquí estaríamos hablando de una auténtica paradoja temporal: "han corregido el fallo 10 minutos antes de conocerlo, oye, todo un record".
#65 ¿recordáis el fallo de Debian con el SSL? ¿recordáis este meneo? y lo que es más importante ¿Que windows tenga fallos convierte a linux en más seguro?, voy a cortarle los frenos del coche a mi vecino, así seguro que mi coche se convierte en un tanque en la carretera, impenetrable por las balas y todo.
#4 AsTuRkInG 
