idkwim/cve-2020-0022Research repository documenting BlueFrag (CVE-2020-0022) Android Bluetooth heap overflow experiments, including GDB crash analysis and memcpy exploitation attempts.
Seems like Android 9-6 have similar Bluetooth subsystem, Android 5 and 4 are different.
Android 9.0
BlueFrag experiments
Patch:
https://android.googlesource.com/platform/system/bt/+/3cb7149d8fed2d7d77ceaa95bf845224c4db3baf
Below I hit the patched condition. OK I think I got it, but somehow I cannot crash the process.
hmmmm
Actually, managed to get signed length value to memcpy()
02-16 01:44:49.096 6423 6471 W bt_hci_packet_fragmenter: reassemble_and_dispatch reassemble_and_dispatch
02-16 01:44:49.096 6423 6471 W bt_hci_packet_fragmenter: reassemble_and_dispatch partial_packet->offset 40 packet->len 304 HCI_ACL_PREAMBLE_SIZE 4
02-16 01:44:49.096 6423 6471 W bt_hci_packet_fragmenter: reassemble_and_dispatch projected_offset 340 partial_packet->len 41
02-16 01:44:49.096 6423 6471 W bt_hci_packet_fragmenter: reassemble_and_dispatch got packet which would exceed expected length of 41. Truncating.
02-16 01:44:49.096 6423 6471 W bt_hci_packet_fragmenter: reassemble_and_dispatch memcpy packet->len 1 packet->offset 4 expr -3
02-16 01:44:49.096 6423 6471 W bt_hci_packet_fragmenter: reassemble_and_dispatch partial_packet->data 0xacb14580 partial_packet->data + partial_packet->offset 0xacb145a8 packet->data 0xa553e110 packet->data + packet->offset 0xa553e114
02-16 01:44:49.097 6423 6469 W bt_hci_packet_fragmenter: fragment_and_dispatch fragment_and_dispatch
Still no crash, but should.....
In the example above, with a memcpy size of -3, this value is interpreted as an unsigned integer (4294967293) and the memcpy continues until there is a page fault due to unmapped memory and the process should terminate.
My phone in 32 bits, maybe that's why. Mobile is Samsung S3 Neo+. Using jemalloc at least at Android 9.0 tests.
¯\_(ツ)_/¯
Well it looks correctly
I suspect you have to open many connections (for some time) and somehow allocate a lot of memory before it crashes.
We are pushing here 4294967293 almost 4GB
¯\_(ツ)_/¯
Swing and leommxj found this weird behavior of Android 8:
https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fbestwing.me%2FAndroid-8.1-memcpy-func.html (Translated from Chinese)
It possibly also affect Android 9. Will check it.
Actually, it can be that this doesn't run in process context, but perhaps in interrupt context. Then maybe the fault could be hidden.
Seeme like. It does Segfaults in GDB. So possibly you can RCE/execute code: