Vulnerabilidad de PHP puede detener millones de servidores - max_input_vars!

Artículo interesante (CVE-2011-4885 para quienes gustan de las referencias), gracias por el aviso. Estaré leyendo esto, pero algunos puntos ya se destacan.

• solo para aclarar, el problema está dentro del nivel lógico, no el servidor web en sí.
• su pregunta de si es posible usar ini_set se basa en la actualización del motor de PHP subyacente, cuando ya ha argumentado que es poco probable que esto suceda para muchos proveedores de hosting. OTOH es probable que cualquier proveedor de alojamiento que actualice su PHP implemente los cambios ini relacionados o proporcione un mecanismo para hacerlo.
• mientras que la mayoría de las empresas de hosting evitarán activamente imponer una actualización importante a sus usuarios, deberían implementar parches de proveedores en implementaciones existentes, y este parche ya ha sido incluido en todas las versiones de producción de 5.3 y 5.2 , Creo que Redhat ahora ha lanzado parches para RHEL actual
• hay al menos 4 lugares diferentes en los que se puede cambiar la configuración de ini en PHP: en el archivo php.ini, en la configuración del servidor web (cuando PHP se implementa como un módulo), en los archivos .htaccess (de nuevo si es un módulo) y en el código PHP en sí, pero no todas las configuraciones se pueden cambiar en todos los lugares, hasta ahora la nueva var. config no está en el manual para decir dónde se puede cambiar.
• para aprovechar esta vulnerabilidad, sería necesario enviar una cantidad significativa de variables en la solicitud: Apache (y probablemente la mayoría de los otros servidores web) permite cierto control sobre el tamaño total de la solicitud, el cuerpo de la solicitud y los datos POST. - también el tiempo de ejecución - el uso efectivo y selectivo de estas opciones de configuración tanto en httpd config como para árboles de directorios específicos utilizando .htaccess se podría usar para mitigar cualquier ataque potencial - teniendo en cuenta la necesidad de soportar (por ejemplo) la carga de archivos.
• la naturaleza de un DOS basado en esta vulnerabilidad es, en efecto, muy similar al problema con las solicitudes de rango en Apache (CVE-2011-3192); aunque es una vulnerabilidad grave, no he visto mucha evidencia de ese defecto siendo ampliamente explotado.

  

Sé que si alguien ataca al servidor, todo el sitio estará inactivo, pero al configurar max_input_vars, al menos mi sitio estará a salvo si alguien ataca mi sitio

No lo entiendo: ciertamente, un ataque basado en esta vulnerabilidad no dará lugar a fugas ni a la modificación de datos / código (AFAICS).

  

Sé que si alguien ataca al servidor, todo el sitio estará inactivo, pero al configurar max_input_vars, al menos mi sitio estará seguro si alguien ataca mi sitio. ¿Esto es correcto?

Argumentaría que a menos que max_input_vars sea más bajo que el valor predeterminado (1000), aún puede suceder con múltiples solicitudes, lo mejor es establecer la cantidad máxima de vars que usa su software, pero es una molestia. para averiguarlo (o imposible si tiene campos dinámicos).

OMI: curita en un cáncer, necesitan cambiar el algoritmo hash para que sea aleatorio.