idkwim/cve-2020-0022Repository di ricerca che documenta gli esperimenti di heap overflow Bluetooth su Android BlueFrag (CVE-2020-0022), incluse l'analisi dei crash con GDB e i tentativi di sfruttamento di memcpy.
Sembra che Android 9-6 abbiano un sottosistema Bluetooth simile, Android 5 e 4 sono diversi.
Android 9.0
Esperimenti BlueFrag
Patch:
https://android.googlesource.com/platform/system/bt/+/3cb7149d8fed2d7d77ceaa95bf845224c4db3baf
Di seguito ho raggiunto la condizione corretta. OK penso di aver capito, ma in qualche modo non riesco a mandare in crash il processo.
hmmmm
In realtà, sono riuscito a ottenere il valore di lunghezza con segno in 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
Ancora nessun crash, ma dovrebbe.....
Nell'esempio sopra, con una dimensione di memcpy pari a -3, questo valore viene interpretato come un intero senza segno (4294967293) e la memcpy continua finché non si verifica un page fault dovuto a memoria non mappata e il processo dovrebbe terminare.
Il mio telefono è a 32 bit, forse è per questo. Il dispositivo mobile è un Samsung S3 Neo+. Utilizzando jemalloc almeno nei test su Android 9.0.```
¯\_(ツ)_/¯
Beh, sembra corretto
Sospetto che tu debba aprire molte connessioni (per un po' di tempo) e in qualche modo allocare molta memoria prima che vada in crash.
Qui stiamo spingendo 4294967293, quasi 4GB``` ¯_(ツ)_/¯
Swing e leommxj hanno scoperto questo strano comportamento di 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
(Tradotto dal cinese)
Potrebbe interessare anche Android 9. Lo verificheremo.
In realtà, potrebbe essere che questo non venga eseguito in contesto di processo, ma forse in contesto di interrupt. In tal caso, forse il fault potrebbe
essere nascosto.