No existe un exploit fácil para esta vulnerabilidad de PHP
There isn't an easy exploit for this PHP vulnerability
Hay un fallo real en PHP y merece atención, pero no es un Log4Shell. Los miles de PoC que circulan en GitHub no funcionan contra una instancia vanilla: muchos dependen de un LFI previo, es decir, exigen que el servidor ya sea vulnerable. El autor sostiene que los LLM convencieron a mucha gente de tener un exploit cuando en realidad no lo tienen.
Los exploits no funcionan.
- nallerooth
Es una afirmación muy extraña viniendo de alguien que intenta sonar entendido en el campo de la ciberseguridad (puede que lo sea, no tengo ni idea de quién es esta persona). Aunque el exploit fuera difícil de usar correctamente, tampoco es que falten grupos ahí fuera intentándolo.
Cualquiera que se tome esto en serio consideraría el hecho de que se reportó un PoC funcional al equipo de seguridad de PHP. Confirmaron la vulnerabilidad y empezaron a hacer mucho ruido sobre su gravedad, reportando 2 CVE y enviando el parche a las distros de Linux antes del lanzamiento oficial del parche.
Intentando entender de qué va el mensaje del post, le di la vuelta a todo en mi cabeza, y el mensaje básicamente es "no necesitas actualizar tus servidores". Que es justo lo que diría alguien con un exploit funcional. O es simplemente ruido en Internet.
- hn773746483
Las redes sociales y los "expertos en ciberseguridad" tuvieron un papel importante en esto. Cosas como "LA UE DICE QUE ESTA ES UNA VULNERABILIDAD URGENTE" e incluso el Primer Ministro de Japón haciendo un anuncio público nocturno. Citan los posts de "los expertos" en redes sociales sobre el aviso inicial, mientras esos mismos supuestos expertos comparten estrategias de mitigación sacadas de la salida de la IA de búsqueda de Google. Ninguna de estas organizaciones ni organismos tenía más detalles que lo que aparecía en los avisos y en las redes sociales. (p. ej. "CVSS 10, ¡¡eso es malo!!")
A mí me parece mucho más parecido a broadpwn, técnicamente grave, de alcance amplio (millones de iPhones), pero que nunca será un botón de PWN que sirva para todo.
Incluso en la era de la IA, no creo que esto llegue a convertirse en un arma como lo fue Eternalblue... pero yo no soy el tipo de ciberseguridad de redes sociales con 15000 seguidores, así que no te tomes mis palabras al pie de la letra ;)
- tibbar
Dos cosas pueden ser ciertas: es un CVE 10 real y explotable, y es lo bastante difícil de construir como para que necesites un buen arnés + un proceso de verificación para evitar que tu LLM haga trampa. Así que puede que el exploit no sea fácil de construir, pero en realidad no requiere los ajustes artificiales que el OP insinuaba.
> Lo que demostramos
> RCE preautenticación en WordPress, Drupal y Joomla
- nemothekid
Para mí, lo extraño fue que no hubiera ningún análisis escrito sobre cómo funcionaba realmente la vulnerabilidad. De verdad que parece que mucha gente dijo "Claude encontró un bug, y Claude dice que es peligroso", pero nadie verificó realmente hasta qué punto es explotable. No es que merezca ignorarse, pero comparado con Heartbleed (donde los exploits había que escribirlos a mano) hay muchos menos PoC activos.
- apexalpha
Esto era absolutamente explotable. El hecho de que existan 1000 PoC que no funcionan no invalida el que sí funciona.
Claro, quizá no en una instalación vanilla, pero la mayoría de la gente no instala Php, usan un contenedor ya hecho o una plataforma que usa Php por debajo.
Ayer simplemente ya no tenía confianza en la seguridad y los datos de mi base de datos son lo bastante importantes como para desconectarla unas horas.
- kgeist
Hoy ejecuté 2 PoC de GitHub: uno efectivamente esperaba que ya estuviera presente un Local File Inclusion (LFI) (así que es solo LFI con pasos extra), y el otro no funcionaba en absoluto tal cual sin algunas modificaciones (aunque usé las mismas imágenes de Docker y todo). El segundo PoC sí que acabó disparando un bug real de escritura obsoleta (stale write), pero no demostró un RCE real; solo disparó una escritura obsoleta. Y entonces me pregunté: ¿es esta la primera vez en la historia que el runtime de PHP tiene un bug de corrupción de memoria? Lo dudo (recuerdo que hace unos años teníamos caídas aleatorias en producción bajo carga alta debido a un bug de opcache). Y si no es el primer bug de corrupción de memoria en el runtime de PHP, ¿por qué se proclama como la peor vulnerabilidad en años?
- nickysielicki
Las imágenes de Docker de Wordpress, joomla y drupal eran todas explotables.
- rectang
Según "Today's PHP Security Release, and How We're Strengthening PHP Security", comentado en https://news.ycombinator.com/item?id=50182987
* Respecto a un CVE, "También se confirmó la ejecución remota de código en PHP-FPM a través de rutas de código a nivel de aplicación".
* Respecto al otro CVE, "Se confirmaron un use-after-free y una caída del worker, y el reportero demostró ejecución remota de código contra una aplicación del mundo real corriendo sobre Apache con mod_php".
Dado que esos exploits existen, espero que los LLM los dupliquen pronto.
- easterncalculus
Vídeo relacionado de LiveOverflow sobre exploits falsos que circulan https://www.youtube.com/watch?v=7CiZmq2llDg
Dicho esto, el OP básicamente está lleno de mierda. Esto es absolutamente explotable y la gente va a simplemente asumir la plataforma y la ABI y rociarlo contra internet, esperando sobre todo mod_php.
- 0x1F8B
Si tanta confianza tiene en que esto no es explotable, esta persona debería levantar un servidor muy básico de nginx con php-fpm corriendo una versión explotable de PHP e invitar a la gente a explotarlo.