Un error tipográfico de un solo carácter, consistente en usar "&" (AND bit a bit) en lugar de "|" (OR bit a bit), provocó una vulnerabilidad crítica de Ejecución Remota de Código (RCE) en Mozilla Firefox. El fallo fue descubierto en el motor JavaScript SpiderMonkey, específicamente en el código de recolección de basura de WebAssembly, donde un desarrollador introdujo el error por equivocación. 

Una vulnerabilidad crítica de Ejecución Remota de Código (RCE) en Mozilla Firefox fue causada por un error de un solo carácter en el código de recolección de basura de WebAssembly del motor JavaScript SpiderMonkey, donde un desarrollador escribió por error "&" (AND bit a bit) en lugar de "|" (OR bit a bit).

El investigador de seguridad Erge descubrió el fallo mientras examinaba el código fuente de Firefox 149 Nightly en busca de inspiración para un desafío CTF y logró explotarlo para obtener ejecución de código dentro del proceso de renderizado de Firefox.

La vulnerabilidad se introdujo en el commit fcc2f20e35ec durante la refactorización de los metadatos de arrays de WebAssembly GC en el archivo js/src/wasm/WasmGcObject.cpp. La línea problemática decía oolHeaderOld->word = uintptr_t(oolHeaderNew) & 1; cuando debería haber sido oolHeaderOld->word = uintptr_t(oolHeaderNew) | 1;.

Debido a la alineación de punteros, la operación AND bit a bit con 1 siempre evaluaba a 0, haciendo que el código almacenara cero en lugar del puntero de reenvío previsto con su bit menos significativo establecido.

Este error de un solo carácter creó una vulnerabilidad de corrupción de memoria al etiquetar incorrectamente arrays de WebAssembly out-of-line (OOL) como inline (IL), lo que provocó que el recolector de basura manejara mal las referencias de memoria.

Detalles técnicos de la vulnerabilidad

El bug existe en la implementación de WebAssembly GC de SpiderMonkey y afecta específicamente a la función WasmArrayObject::obj_moved(), que se llama cuando el recolector de basura mueve arrays de Wasm entre ubicaciones de memoria.

Cuando se reubica un array OOL, el GC debe dejar un puntero de reenvío en el encabezado del buffer antiguo para que Ion (el compilador JIT de SpiderMonkey) pueda encontrar la nueva ubicación de los datos. El puntero de reenvío se distingue de los encabezados normales estableciendo su bit menos significativo (LSB) en 1.

El error tipográfico hizo que el puntero de reenvío se estableciera en 0, lo que satisfacía inadvertidamente la condición para identificar un array como inline en la función isDataInline(): return (headerWord & 1) == 0;.

Esta vulnerabilidad solo es explotable dentro de funciones WebAssembly optimizadas por Ion, ya que el mecanismo no existe en el compilador Baseline.

El investigador Erge desarrolló un exploit de prueba de concepto que logró primitivas de lectura/escritura arbitrarias y RCE completo mediante los siguientes pasos:

1. Provocó una recolección de basura menor, haciendo que se almacenara 0 en el puntero de reenvío.
2. La función wasm::Instance::updateFrameForMovingGC de Ion identificó incorrectamente el array como inline debido al puntero de reenvío en cero.
3. La función devolvió la dirección del array antiguo en lugar de la nueva, impidiendo la actualización de los marcos de pila.
4. Creó una condición de uso después de liberar (UAF) mientras Ion seguía usando la memoria del array liberado.
5. Realizó un heap spraying con valores como 0x41414141 para reclamar la memoria liberada.
6. Logró lectura/escritura arbitraria controlando la dirección base del array OOL interpretado.
7. Eludió ASLR rociando objetos que contenían punteros relativos al binario.
8. Sobrescribió una vtable para secuestrar RIP y ejecutar comandos del sistema arbitrarios.

El exploit final logró abrir una shell (/bin/sh) llamando a la función system().

Cronología de divulgación y parcheo

La divulgación de la vulnerabilidad siguió una línea de tiempo rápida:

La vulnerabilidad solo afectó a las compilaciones Nightly de Firefox 149 y nunca llegó a ninguna versión de lanzamiento, evitando su explotación masiva. El equipo de seguridad de Mozilla respondió rápidamente para parchear el fallo, y ambos investigadores que descubrieron el bug de forma independiente recibieron recompensas divididas.