¿Se pueden proteger las vulnerabilidades de la línea de comandos de cadenas en implementaciones CGI antiguas de PHP sin actualizar las versiones de PHP?

Question

¿Se pueden proteger las vulnerabilidades de la línea de comandos de cadenas en implementaciones CGI antiguas de PHP sin actualizar las versiones de PHP?

#1 de Lucas Kauffman (1 votos)

0

Recientemente recibimos esto de una auditoría de seguridad:

PHP es un lenguaje de scripts de propósito general que se puede incrustar en HTML. Existe una vulnerabilidad en las versiones de PHP anteriores a 5.3.12 y 5.4.2 debido a un análisis incorrecto de los parámetros de la cadena de consulta cuando se configura con una configuración basada en CGI (por ejemplo, mod_cgid de Apache). Los parámetros de cadena de consulta procesados suministrados a un archivo PHP arbitrario se analizan incorrectamente como argumentos de línea de comando. Los atacantes remotos podrían aprovechar este problema para pasar los interruptores de la línea de comandos (por ejemplo, -s, -c, -n, -f, -r, -B, -R, -F, -E, -t, etc.) al php-cgi binario y divulgar información de código fuente potencialmente sensible o ejecutar código arbitrario en sistemas vulnerables con los privilegios del servidor web. La explotación exitosa requiere que el servidor HTTP cumpla con la sección 4.4 (La línea de comandos del script) de la solicitud de comentarios de la Interfaz de puerta de enlace común (CGI) (RFC 3875).

Tenemos múltiples entornos PHP, todos ejecutándose como CGI / Fast CGI bajo IIS. Actualizar todas las versiones de PHP es, por supuesto, la solución ideal a largo plazo. Sin embargo, eso llevará algún tiempo, pruebas y planificación. Algunos de los servidores son administrados por hosts externos con los que contratamos, lo que complicará aún más las actualizaciones de la versión.

¿Cómo puedo verificar entornos específicos para esta vulnerabilidad? ¿Hay alguna manera de evitar que los atacantes remotos exploten esto sin una actualización de la versión completa?

webserver php

pregunta Beofett 19.11.2013 - 16:52

fuente

1 respuesta

Lea otras preguntas en las etiquetas webserver php

¿Sistema operativo minimalista para mejorar la seguridad ssh? ¿Cuál es la mejor manera de implementar 2FA basado en teléfono?

score 1 · Accepted Answer

PHP lanzó un boletín aquí:

El equipo de desarrollo de PHP desea anunciar lo inmediato.   Disponibilidad de PHP 5.4.2. Esta versión ofrece una solución de seguridad.

Hay una vulnerabilidad en ciertas configuraciones basadas en CGI que se ha ido   Desaparecido durante al menos 8 años. La sección 7 de la especificación CGI establece:

Algunos sistemas admiten un método para suministrar una matriz de cadenas a la   Script CGI. Esto solo se usa en el caso de una consulta 'indexada'. Esta   se identifica mediante una solicitud HTTP "GET" o "HEAD" con una búsqueda de URL   cadena que no contiene ningún carácter "=" sin codificar. Así que pide que   no tienen un "=" en la cadena de consulta se tratan de forma diferente a   Los que lo hacen en algunas implementaciones CGI. Para PHP esto significa que un   la solicitud que contiene? -s puede volcar el código fuente PHP para la página, pero   una solicitud que tenga? -s & a = 1 está bien.
Una gran cantidad de sitios ejecutan PHP como un módulo de Apache a través de   mod_php o utilizando php-fpm bajo nginx. Ninguna de estas configuraciones son   vulnerable a esto El CGI estilo shebang recto tampoco parece   ser vulnerable.

Si está utilizando Apache mod_cgi para ejecutar PHP, puede ser vulnerable. A   vea si está agregando? -s al final de cualquiera de sus URL. Si tú ves   Tu código fuente, eres vulnerable. Si su sitio rinde normalmente,   usted no.   Para arreglar esta actualización a PHP 5.3.12 o PHP 5.4.2. Reconocemos que desde   esta es una forma bastante anticuada de ejecutar PHP, puede que no sea factible   actualizar estos sitios a una versión moderna de PHP, por lo que una alternativa es   para configurar su servidor web para no permitir este tipo de solicitudes con   cadenas de consulta que comienzan con un "-" y que no contienen un "=" a través de.   Agregar una regla como esta no debería romper ningún sitio. Para usar Apache   mod_rewrite se vería así:
RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC]
RewriteRule ^(.*) $1? [L]
Si está escribiendo su propia regla, asegúrese de tomar el urlencoded?% 2ds versión en cuenta.

Tenga en cuenta que esto es específicamente para mod_cgi en Apache .

Para asegurarse de que no es vulnerable, pruebe si el método descrito anteriormente también es aplicable para sus servidores IIS. Si es así, debe asegurarse de que para cada servidor IIS debe habilitar url-rewrite y hacer Seguro que imitas el mismo comportamiento que el escrito arriba.

La solución a largo plazo no es parchear su software, su objetivo a largo plazo debe ser la administración adecuada de parches y un mejor control de su ciclo de vida de desarrollo de software. Parches como estos deberían poder extenderse en menos de dos semanas (este es el objetivo).

También debe tener cuidado de no perder de vista las vulnerabilidades, el hecho de que el equipo de auditoría tenga que recordarle las vulnerabilidades críticas demuestra que también falta la administración de vulnerabilidades.