PHP2Shell: la IA descubre una RCE crítica en PHP

Artículo original ↗ Discusión en Hacker News ↗

El análisis de código asistido por IA ha descubierto dos vulnerabilidades críticas de ejecución remota de código en PHP, un lenguaje que sustenta una gran parte de la web mediante plataformas como WordPress, Drupal y MediaWiki. Los comentaristas examinan cómo errores de seguridad de memoria en C, de larga data, escondidos en código PHP con décadas de antigüedad, pasaron desapercibidos, la confusa cronología de la divulgación responsable y la fuga, y el papel de varios modelos de IA y firmas de seguridad tanto en encontrar como en publicar las fallas. El hilo también se amplía hacia preocupaciones sobre pilas tecnológicas heredadas, la viabilidad de endurecer despliegues de PHP y si lenguajes más nuevos y seguros respecto a la memoria, junto con un sandboxing agresivo, deberían reemplazar a los intérpretes basados en C para servicios de Internet de alta exposición.

Impacto y alcance

  • La discusión coincide en que la RCE es un asunto muy grave dada la dominancia de PHP (WordPress, Drupal, foros, webmail, LMS, Nextcloud, etc.).
  • Algunos la comparan con Log4Shell o incluso EternalBlue por su impacto potencial; otros señalan que la fiabilidad del exploit y el daño real en el mundo todavía no están claros.
  • Gobiernos y CERTs están desconectando sitios o emitiendo alertas de máximo nivel; los administradores se apresuran a parchear o a poner proxies de mitigación delante de PHP.
  • Algunos sostienen que unos servidores web correctamente aislados no deberían ser un fácil “pie en la puerta”, pero muchos reconocen que en la práctica a menudo sí lo son.

Papel de la IA

  • Se utilizaron múltiples sistemas de IA (de distintos proveedores) para el análisis de código, el desarrollo del exploit, la validación y la detección.
  • Los comentaristas ven esto como un caso de uso sólido: la IA puede machacar décadas de código C que los humanos rara vez revisan.
  • Otros critican el fuerte marketing, la marca y el estilo de la pieza “tech-noir”, y temen una exageración del papel de la IA.
  • Se debate si la IA descubrió algo realmente nuevo o si redescubrió problemas ya informados o parcialmente corregidos.
  • Algunos temen que los modelos orientados a defensores estén demasiado restringidos, mientras que los atacantes pueden usar herramientas menos limitadas.

Cronología de la divulgación y fuga

  • Informado en agosto, reconocido por PHP a finales de septiembre, parcheado y divulgado a finales de octubre; muchos consideran que dos meses es demasiado dado el nivel de gravedad.
  • Confusión en torno a un bug de OOM presentado anteriormente que se marcó como corregido; los comentarios sugieren que las correcciones previas eran estrechas y no abordaban la causa raíz más amplia.
  • La divulgación coordinada implicó a muchos proveedores y distribuciones, aumentando el riesgo de fuga.
  • Los IDs CVE y detalles inexactos se filtraron pronto, y luego una firma publicó por accidente un vídeo de PoC; otro proveedor distribuyó imágenes parcheadas horas antes de que terminara el embargo, lo que generó críticas.

Cuestiones técnicas y del lenguaje

  • Las vulnerabilidades tienen su origen en código C muy antiguo: manejo de OOM, use-after-free, progreso de carga de sesiones de PHP, internals de HashTable, OPcache, etc.
  • Varios comentarios dicen que una vez que es posible la corrupción del heap, normalmente se puede lograr RCE mediante punteros a funciones o primitivas similares.
  • Largos subhilos debaten si C “no es adecuado para el propósito” en software expuesto a Internet; otros sostienen que C está bien, pero requiere una disciplina y unas herramientas extremas.
  • Muchos abogan por mover componentes críticos a lenguajes con seguridad de memoria y depender más del sandboxing y del aislamiento estricto.

Ecosistema de PHP y alternativas

  • La discusión retoma la ubicuidad de PHP y su condición de “legado pero enorme”, especialmente a través de WordPress.
  • Algunos administradores de sistemas ya tratan los servidores PHP como hostiles (VLANs aisladas, configuraciones endurecidas) y se sienten reivindicados.
  • Otros usan esto como otro argumento para migrar a soluciones basadas en sitios estáticos o CMS no basados en PHP.