idkwim/cve-2020-0022Dépôt de recherche documentant les expériences de dépassement de tas Bluetooth Android BlueFrag (CVE-2020-0022), incluant l'analyse de crash GDB et les tentatives d'exploitation memcpy.
Il semble qu'Android 9-6 aient un sous-système Bluetooth similaire, Android 5 et 4 sont différents.
Android 9.0
Expériences BlueFrag
Correctif :
https://android.googlesource.com/platform/system/bt/+/3cb7149d8fed2d7d77ceaa95bf845224c4db3baf
Ci-dessous, j'ai atteint la condition corrigée. OK je pense avoir compris, mais d'une manière ou d'une autre je n'arrive pas à faire planter le processus.
hmmmm
En fait, j'ai réussi à obtenir une valeur de longueur signée jusqu'à 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
Toujours pas de crash, mais ça devrait.....
Dans l'exemple ci-dessus, avec une taille de memcpy de -3, cette valeur est interprétée comme un entier non signé (4294967293) et le memcpy continue jusqu'à ce qu'il y ait un défaut de page dû à une mémoire non mappée et le processus devrait se terminer.
Mon téléphone est en 32 bits, c'est peut-être pour ça. Le mobile est un Samsung S3 Neo+. Utilisation de jemalloc au moins lors des tests sous Android 9.0.```
¯\_(ツ)_/¯
Eh bien, ça semble correct
Je suppose qu'il faut ouvrir de nombreuses connexions (pendant un certain temps) et allouer beaucoup de mémoire d'une manière ou d'une autre avant que ça ne plante.
On pousse ici 4294967293, presque 4 Go``` ¯_(ツ)_/¯
Swing et leommxj ont découvert ce comportement étrange d'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
(Traduit du chinois)
Cela pourrait aussi affecter Android 9. Nous vérifierons.
En fait, il se peut que cela ne s'exécute pas en contexte de processus, mais peut-être en contexte d'interruption. Alors peut-être que le défaut pourrait
être masqué.