Acceso fuera de límites a memoria en V8 en Google Chrome anterior a 120.0.6099.224

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

Una vulnerabilidad recién divulgada de acceso a memoria fuera de límites en el motor JavaScript V8 de Chrome (CVE-2024-0519), conocida por estar explotada en entornos reales, ha suscitado preocupaciones sobre la seguridad de navegadores, Node.js, aplicaciones Electron y otro software que incrusta V8, especialmente en sistemas sin parches o heredados como Windows 7. Los comentaristas analizan cómo la complejidad de los compiladores JIT, los lenguajes inseguros en memoria y los límites del fuzzing hacen que estos fallos sutiles sean difíciles de prevenir, incluso para equipos con muchos recursos. El hilo también examina el significado de código “confiable” frente a “no confiable”, el valor real del sandboxing y si alternativas como desactivar JIT o usar herramientas de nivel superior o formalmente verificadas pueden reducir de forma significativa el riesgo.

Asignación de CVE y parches

  • Los comentaristas intentan localizar el diff exacto de git; se mencionan múltiples commits candidatos e IDs de errores, con cierta confusión entre CVE-2024-0517, -0518 y -0519.
  • Un participante señala que las notas de lanzamiento de Chrome vinculan 0519 con un número de incidencia distinto al de un commit sugerido, por lo que la asignación precisa sigue siendo algo incierta.
  • Los avisos de Fedora mencionan tres CVE distintas de V8 (confusión de tipos, lectura OOB, escritura OOB), lo que indica varios problemas del compilador/tiempo de ejecución en un periodo similar.

Versiones y productos afectados

  • La lista CPE de NVD sugiere impacto desde Chrome 9, pero la gente subraya que estos rangos a menudo no están validados y pueden ser obviamente erróneos (ejemplo: un fallo de WebGPU “afectando” a versiones anteriores a que WebGPU existiera).
  • Dado que el fallo parece relacionado con el compilador Maglev, que llegó alrededor de Chrome 114, es probable que versiones antiguas de Chrome (por ejemplo, 60) no estén afectadas, aunque esto se infiere y no está confirmado.
  • Como los tres CVE están en V8, cualquier cosa que incruste V8 (Node.js, aplicaciones Electron, incrustadores personalizados, plataformas serverless/edge) podría verse expuesta si ejecuta JavaScript no confiable o semiconfiable.

Código no confiable, sandboxing e impacto

  • Debate sobre qué significa “código no confiable”:
    • Una postura: cualquier código que no haya sido auditado a fondo es no confiable, así que las pilas típicas de dependencias de Node califican.
    • Otra postura: si lo ejecutas en tu proceso, de facto le estás confiando; “no confiable” es el código que esperas que pueda ser malicioso y que debe ejecutarse en un sandbox.
  • Los navegadores y muchas aplicaciones dependen fuertemente de V8 como sandbox para entradas hostiles; fallos como este erosionan ese supuesto.
  • El análisis del exploit (para 0517) logra potentes capacidades de lectura/escritura dentro del sandbox de V8/“Ubercage” mediante una cadena basada en Wasm; el sandbox externo a nivel del SO de Chrome no parece estar roto en la cadena pública.
  • Algunos señalan que incluso la ejecución de código solo dentro de un sandbox puede filtrar o desanonimizar usuarios, dependiendo de los detalles de la plataforma.

JIT, fuzzing y seguridad del lenguaje

  • Varios comentarios enfatizan que el fuzzing, aunque muy usado en Chrome/V8, es estocástico y puede pasar por alto fallos profundos durante años.
  • Otros sostienen que los motores JIT pueden compilar incorrectamente independientemente del lenguaje de implementación; los lenguajes seguros en memoria no eliminan esta clase, aunque sí eliminan muchos errores de memoria bruta en otros lugares.
  • Hay discusión sobre diseños alternativos: intérpretes más seguros, desactivar el JIT (compatible en los navegadores principales) y marcos JIT de nivel superior (por ejemplo, estilo Graal/Truffle) para reducir la manipulación manual de IR.
  • El consenso: nadie sabe cómo construir JITs grandes y de alto rendimiento y navegadores sin fallos de seguridad; los lenguajes seguros en memoria ayudan, pero no son una solución completa.

Modelos de amenaza y riesgo operativo

  • Se establece una distinción entre “niños de cinco años aburridos” (atacantes de bajo esfuerzo) y los estados-nación; estos últimos a menudo pueden tener éxito pese a defensas fuertes.
  • La mayoría de las brechas del mundo real siguen derivándose de errores triviales (software sin parchear, contraseñas malas) más que de 0-days nuevos de V8, así que las actualizaciones oportunas importan más para la mayoría de las organizaciones.
  • Hay inquietud por los intermediarios de exploits que venden este tipo de fallos a gobiernos y por la escala de navegadores sin parchear.

Sistemas heredados y exposición a largo plazo

  • Chrome en Windows 7 está bloqueado en la versión 109; estos sistemas no recibirán correcciones para nuevos fallos de V8.
  • Algunos argumentan que quien ejecuta Windows 7 en red “no se preocupa por la seguridad”; otros responden que una máquina Windows 7 aislada y protegida por firewall puede estar expuesta principalmente a través de su navegador.
  • Las observaciones de que Windows 7/8/XP aún conservan una cuota de mercado no trivial llevan a preocuparse por una base instalada grande y permanentemente vulnerable.