Ninguna medida casera permite bloquear por completo los dos fallos críticos de PHP conocidos como PHP2Shell antes de la actualización que se publicará hoy a las 14:00 UTC, y el ajuste de configuración que se está promocionando como solución alternativa no es suficiente por sí solo, según ha rectificado la empresa de seguridad que lo propuso.
PHP lanzará el parche el 21 de octubre a las 14:00 UTC para dos vulnerabilidades que califica con 9,2 sobre 10, y no ha proporcionado ninguna mitigación propia. Hasta que se pueda instalar, lo que reduce el riesgo es sacar PHP expuesto de internet o ponerlo detrás de controles de acceso, limitar lo que un servidor comprometido puede alcanzar y tener la actualización lista para aplicarla en cuanto esté disponible.
Cloudflare afirma que está observando intentos tempranos de explotación y ha desplegado reglas de emergencia para los sitios que protege, que describe como un paliativo hasta que se aplique el parche. No se ha confirmado ningún compromiso, el código de explotación público que circula no ha demostrado funcionar y ninguno de los dos fallos figura en el catálogo de vulnerabilidades explotadas conocidas de CISA.
PHP no ha especificado qué versiones están afectadas, qué parte de PHP está implicada ni si algún cambio de configuración modifica el riesgo; según el proyecto, los detalles completos y las versiones corregidas se darán a conocer con la publicación.
⚡ ACTUALIZACIÓN — PHP publica parches de emergencia para dos fallos RCE críticos de PHP2Shell mientras surgen intentos de explotación
En el momento de redactar este artículo, la versión corregida aún no estaba disponible. Por tanto, nadie fuera del grupo que descubrió los fallos puede probar si una defensa determinada funciona, y por eso los consejos que siguen pretenden reducir el riesgo, no garantizar la seguridad.
El ajuste que le dijeron que cambiara no es una protección
La solución que se difunde en redes sociales y blogs de seguridad es una línea en un archivo de configuración de PHP: session.upload_progress.enabled=0. Desactiva el Progreso de Carga de Sesión, una función de PHP habilitada por defecto que registra el avance de una carga de archivo para que otra solicitud pueda consultarlo.
GMO Flatt Security, una firma de seguridad de Tokio, sugirió establecerlo temprano el 21 de octubre, argumentando que no podía asegurar que el cambio abordara completamente los fallos, pero que creía que ayudaría con cierta probabilidad.
Más tarde ese mismo día, la empresa se retractó. En una actualización con marca de tiempo de las 14:00 hora de Japón (05:00 UTC), afirmó que el ajuste por sí solo no es una solución completa y que se esperan ataques que lo eludan. Recomendó a los administradores preparar su actualización, vigilar el tráfico de ataque antes del lanzamiento y aplicar el parche en cuanto esté disponible.
Dos personas del proyecto PHP dijeron lo mismo con más contundencia. Respondiendo a alguien que sugirió que el ajuste de progreso de carga podría parchear el fallo, Gina Peter Banyard, desarrolladora del núcleo de PHP y redactora de documentación financiada por la PHP Foundation, escribió: «Lo único que puedo decir es que la única mitigación es parchear / actualizar PHP. Lamentablemente sé demasiado». Joe Ferguson, el gestor de la versión PHP 8.6 que viene, lo resumió más breve: «Los ajustes de ini no te salvarán».
El ajuste no es fiable por dos razones. GMO Flatt espera una forma de eludirlo pero no ha dicho cuál es. Y la idea de que el fallo está en el Progreso de Carga de Sesión es una conjetura: PHP no lo ha confirmado, la propia empresa dijo que solo sostiene lo que su investigación coincide con PHP2Shell, y una auditoría de código independiente argumenta que el error específico que otros describen en esa función no existe en PHP publicado. Esa auditoría proviene de una cuenta anónima y el propio código de PHP lo resolverá, pero es una razón más para no tratar el ajuste como un escudo.
No todos están de acuerdo. Un proveedor, Upwind, todavía incluye el ajuste como mitigación inmediata, difundiendo el análisis de otro investigador en lugar de sus propias pruebas. watchTowr, que reprodujo uno de los fallos, afirma que «no hay parche ni solución alternativa confirmados en este momento».
Si ya lo has establecido
Nadie te está diciendo que deshagas el cambio. La instrucción es solo no considerarlo una protección. El propio manual de PHP ya aconseja desactivar la función cuando una aplicación no utiliza barras de progreso de carga, porque los nombres de archivo y de campo almacenados «no se validan y pueden contener código PHP». Si lo activaste por error en un lugar que lo necesita, el único coste es que las barras de progreso de carga dejen de funcionar.
Comprueba que el cambio está realmente en vigor en el proceso que sirve el tráfico web, no en la línea de comandos. El ajuste es INI_PERDIR, por lo que se puede establecer en php.ini, .htaccess o .user.ini.
Un archivo .user.ini solo lo leen las versiones CGI y FastCGI de PHP, no el módulo de Apache, y PHP lo relee solo cada 300 segundos por defecto, por lo que un cambio allí puede tardar cinco minutos en aplicarse.
Bajo el módulo de Apache, usa .htaccess o la configuración del servidor. Confirma el valor en PHP-FPM o mod_php, el que sirva tu sitio, no con php -i en el shell.
Si puedes parchear a las 14:00 UTC
Prepárate ahora. El consejo de GMO Flatt es confirmar los pasos de actualización y las comprobaciones posteriores, ensayar cualquier cambio de configuración y alinear a las personas y aprobaciones para un posible reinicio de emergencia. Cuando llegue el parche, actualiza el entorno de ejecución que sirve las solicitudes web, que es PHP-FPM, mod_php o CGI, no la aplicación que se ejecuta encima.
PHP solo publica correcciones para sus cuatro ramas soportadas, de la 8.2 a la 8.5. Las versiones exactas que incluyen el parche y hasta dónde se remontan los fallos se anunciarán con la publicación.
The Hacker News informó sobre el soporte de ramas y los antecedentes más amplios en su cobertura anterior de la divulgación.
Si no puedes parchear de inmediato o ejecutas una versión no soportada
Cuando no es posible una actualización inmediata, CERT-EU aconseja a las organizaciones «considerar aislar las aplicaciones expuestas a internet de las redes públicas hasta que se pueda aplicar una solución». Banyard expresó el mismo punto desde dentro del proyecto: apagar un servidor durante un día «podría ser lo más sensato. Pero eso está lejos de ser algo razonable de exigir a la mayoría de la gente». Sin llegar a apagarlo, restringe el alcance: coloca el sitio detrás de una VPN, clientes en lista blanca o acceso autenticado en el borde, y verifica que el tráfico no pueda llegar al origen directamente sorteando esos controles.
Reduce lo que un atacante obtiene si el servidor es tomado. Los otros pasos de GMO Flatt son reducir los datos almacenados en el servidor, reducir sus privilegios, eliminar credenciales almacenadas, incluidos roles en la nube, y asegurar que el registro esté habilitado y se guarde en una ubicación segura para poder investigar después.
Las ramas anteriores a la 8.2, incluidas la 8.1, 7.x y 5.x, están al final de su vida útil y no reciben correcciones de PHP. Para esas, actualiza, desconecta el sistema o aíslalo; una distribución de Linux o un proveedor de alojamiento puede aplicar un parche retroportado según su propio calendario.
Algunos investigadores señalan un paliativo más fuerte que el ajuste de sesión: bloquear en el servidor web las solicitudes que llevan un cuerpo multipart/form-data, antes de que lleguen a PHP, porque el fallo sospechado está en cómo PHP lee ese cuerpo. Si lo pruebas, bloquea más allá de POST. PHP 8.4 añadió una función, request_parse_body(), que lee cuerpos multipart también en otros métodos, por lo que una regla solo para POST se puede sortear.
El coste es real: las cargas de archivos, y algunos formularios que envían multipart sin archivo, dejan de funcionar hasta que elimines el bloqueo. Y al igual que el ajuste de sesión, esto apunta a una vía de entrada sospechada, no confirmada, por lo que reduce la exposición en lugar de garantizar la seguridad.
Un cortafuegos de aplicaciones web es aquí un paliativo, no una solución, y Cloudflare lo dice ella misma. Ha desplegado reglas de emergencia para las rutas de explotación conocidas, incluido el nivel gratuito, que su CTO califica como «SOLO un paliativo» antes de parchear. Tales reglas solo ven el tráfico que pasa por Cloudflare y pueden pasar por alto nuevas rutas de ataque a medida que aparecen.
Si otra persona gestiona tu PHP
Actualizar WordPress, Laravel u otra aplicación no actualiza el entorno de ejecución de PHP subyacente; eso proviene de tu paquete de servidor, proveedor o imagen de contenedor. En alojamiento gestionado o compartido, pregunta a tu proveedor cuándo estará disponible una compilación de PHP corregida y pídele que esté preparado.
Los proveedores de alojamiento crean sus paquetes solo después de que PHP publique la corrección: CloudLinux, por ejemplo, dice que sus paquetes actualizados dependen del lanzamiento upstream y se publicarán cuando estén listos.
Una trampa si ejecutas PHP desde los paquetes de una distribución de Linux: Debian, Ubuntu y similares retroportan las correcciones de seguridad a la versión que ya ejecutas en lugar de moverte a una nueva, por lo que un paquete parcheado puede mantener un número de versión antiguo. No juzgues si estás corregido solo por la cadena de versión; busca el CVE en el registro de cambios del paquete o compara la versión exacta del paquete con el aviso de tu distribución.
Qué comprobar cuando llegue la publicación
La explotación es temprana y no confirmada. Cloudflare informa de intentos incipientes; watchTowr dice que reprodujo un fallo pero no ha informado de ataques; el código de explotación público que circula no ha demostrado funcionar; y ninguno de los dos fallos figuraba en el catálogo de vulnerabilidades explotadas conocidas de CISA en la última comprobación del 21 de octubre.
Un investigador ha publicado un vídeo que supuestamente demuestra la cadena de explotación, y la auditoría mencionada afirma que el código de prueba de concepto en circulación no se ejecuta contra PHP publicado. Trata todo esto como una instantánea que puede cambiar de una hora a otra.
Cuando se publique la corrección, verifica la versión corregida para tu rama, qué versiones enumera PHP como afectadas, si PHP confirma o rechaza algún ajuste como mitigación, y si el código de sesión cambió, lo que también responde a la disputa sobre dónde reside el fallo.
Las versiones corregidas y el aviso aparecerán en php.net y en los avisos de seguridad de GitHub de PHP, donde el proyecto asigna sus propios identificadores. Después de actualizar, revisa tus registros en busca de cualquier actividad ocurrida antes de parchear.
Deja una respuesta