Re: usb/media/pvrusb2: warning in pvr2_send_request_ex/usb_submit_urb

[Andrey Konovalov]

On Wed, Sep 20, 2017 at 9:33 PM, Mike Isely  wrote:

Hi Mike!

>
> What you have here is way beyond just feeding random crap in via the
> syscall interface.  To cause this you have to fake the presence of a
> pvrusb2 compatible *hardware* USB device and then lie about its endpoint
> configuration.  Is that really a concern here?  Are we now saying that
> any kernel driver which talks via USB must now also specifically verify
> the exact expected USB endpoint configuration?  Where does that end?
> How about the vendor-specific RPC protocol that the hardware actually
> implements over the bulk endpoint?  It's likely that the pvrusb2 driver
> may be making assumptions about the expected responses over that
> protocol.

The main assumption here is that an attacker has physical access to a
USB port on a machine. In such case a 100$ Facedancer21 board [1] or a
5$ Raspberry Pi Zero [2] in device mode can be used to emulate
arbitrary USB devices and exploit bugs in the kernel (to execute
arbitrary code or to leak data). USB device descriptors during
enumeration phase and all subsequently received from the device
packets (including vendor-specific protocols) should be considered
untrusted input and checked accordingly.

>
> Please realize that I'm not dismissing this.  I can see some merit in
> this.  But I'm just a bit surprised that now we're going this far.  Is
> this really the intention?  You're talking about code
> (pvrusb2_send_request_ex()) that hasn't changed in about 10 years.
> With this level of paranoia there's got to be a pretty target-rich
> environment over the set of kernel-supported USB devices.

Yes, the intention is to fuzz Linux kernel USB drivers (and USB core
code) by connecting random malformed USB devices and by sending
garbage during subsequent communication.

The fact that the code hasn't changed doesn't mean that it's not buggy :)

>
> To take this another step, wouldn't that same level of paranoia be a
> concern for any externally connected PCI-Express device?  Because that's
> another external way into the computer that involves very non-trivial
> and very hardware-centric protocols.  Thunderbolt devices would be an
> example of this.

At this point being able to connect a PCI-Express device usually leads
to being able to do a DMA attack. But sure, exploitable bugs in
PCE-Express device drivers would be a viable attack vector for systems
with proper IOMMU support. Same goes for any other hot-pluggable
externally accessible port/protocol.

>
>   -Mike

[1] https://int3.cc/products/facedancer21

[2] https://www.raspberrypi.org/products/raspberry-pi-zero/

Thanks!

>
>
> On Wed, 20 Sep 2017, Andrey Konovalov wrote:
>
>> Hi!
>>
>> I've got the following report while fuzzing the kernel with syzkaller.
>>
>> On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
>>
>> There seems to be no check on endpoint type before submitting bulk urb
>> in pvr2_send_request_ex().
>>
>> usb 1-1: New USB device found, idVendor=2040, idProduct=7500
>> usb 1-1: New USB device strings: Mfr=0, Product=255, SerialNumber=0
>> usb 1-1: Product: a
>> gadgetfs: configuration #6
>> pvrusb2: Hardware description: WinTV HVR-1950 Model 750xx
>> usb 1-1: BOGUS urb xfer, pipe 3 != type 1
>> [ cut here ]
>> WARNING: CPU: 1 PID: 2713 at drivers/usb/core/urb.c:449
>> usb_submit_urb+0xf8a/0x11d0
>> Modules linked in:
>> CPU: 1 PID: 2713 Comm: pvrusb2-context Not tainted
>> 4.14.0-rc1-42251-gebb2c2437d80 #210
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> task: 88006b7a18c0 task.stack: 880069978000
>> RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448
>> RSP: 0018:88006997f990 EFLAGS: 00010286
>> RAX: 0029 RBX: 880063661900 RCX: 
>> RDX: 0029 RSI: 86876d60 RDI: ed000d32ff24
>> RBP: 88006997fa90 R08: 11000d32fdca R09: 
>> R10:  R11:  R12: 11000d32ff39
>> R13: 0001 R14: 0003 R15: 880068bbed68
>> FS:  () GS:88006c60() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 01032000 CR3: 6a0ff000 CR4: 06f0
>> Call Trace:
>>  pvr2_send_request_ex+0xa57/0x1d80 
>> drivers/media/usb/pvrusb2/pvrusb2-hdw.c:3645
>>  pvr2_hdw_check_firmware drivers/media/usb/pvrusb2/pvrusb2-hdw.c:1812
>>  pvr2_hdw_setup_low drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2107
>>  pvr2_hdw_setup drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2250
>>  pvr2_hdw_initialize+0x548/0x3c10 
>> drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2327
>>  pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:118
>>  pvr2_context_thread_func+0x361/0x8c0
>> drivers/media/usb/pvrusb2/pvrusb2-context.c:167
>>  kthread+0x3a1/0x470 kernel/kthread.c:231
>>  ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
>> Code: 48 8b 85 30 ff ff ff 48 8d b8 98 

Re: usb/media/pvrusb2: warning in pvr2_send_request_ex/usb_submit_urb

[Mike Isely]

What you have here is way beyond just feeding random crap in via the 
syscall interface.  To cause this you have to fake the presence of a 
pvrusb2 compatible *hardware* USB device and then lie about its endpoint 
configuration.  Is that really a concern here?  Are we now saying that 
any kernel driver which talks via USB must now also specifically verify 
the exact expected USB endpoint configuration?  Where does that end?  
How about the vendor-specific RPC protocol that the hardware actually 
implements over the bulk endpoint?  It's likely that the pvrusb2 driver 
may be making assumptions about the expected responses over that 
protocol.

Please realize that I'm not dismissing this.  I can see some merit in 
this.  But I'm just a bit surprised that now we're going this far.  Is 
this really the intention?  You're talking about code 
(pvrusb2_send_request_ex()) that hasn't changed in about 10 years.  
With this level of paranoia there's got to be a pretty target-rich 
environment over the set of kernel-supported USB devices.

To take this another step, wouldn't that same level of paranoia be a 
concern for any externally connected PCI-Express device?  Because that's 
another external way into the computer that involves very non-trivial 
and very hardware-centric protocols.  Thunderbolt devices would be an 
example of this.

  -Mike


On Wed, 20 Sep 2017, Andrey Konovalov wrote:

> Hi!
> 
> I've got the following report while fuzzing the kernel with syzkaller.
> 
> On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
> 
> There seems to be no check on endpoint type before submitting bulk urb
> in pvr2_send_request_ex().
> 
> usb 1-1: New USB device found, idVendor=2040, idProduct=7500
> usb 1-1: New USB device strings: Mfr=0, Product=255, SerialNumber=0
> usb 1-1: Product: a
> gadgetfs: configuration #6
> pvrusb2: Hardware description: WinTV HVR-1950 Model 750xx
> usb 1-1: BOGUS urb xfer, pipe 3 != type 1
> [ cut here ]
> WARNING: CPU: 1 PID: 2713 at drivers/usb/core/urb.c:449
> usb_submit_urb+0xf8a/0x11d0
> Modules linked in:
> CPU: 1 PID: 2713 Comm: pvrusb2-context Not tainted
> 4.14.0-rc1-42251-gebb2c2437d80 #210
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: 88006b7a18c0 task.stack: 880069978000
> RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448
> RSP: 0018:88006997f990 EFLAGS: 00010286
> RAX: 0029 RBX: 880063661900 RCX: 
> RDX: 0029 RSI: 86876d60 RDI: ed000d32ff24
> RBP: 88006997fa90 R08: 11000d32fdca R09: 
> R10:  R11:  R12: 11000d32ff39
> R13: 0001 R14: 0003 R15: 880068bbed68
> FS:  () GS:88006c60() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 01032000 CR3: 6a0ff000 CR4: 06f0
> Call Trace:
>  pvr2_send_request_ex+0xa57/0x1d80 
> drivers/media/usb/pvrusb2/pvrusb2-hdw.c:3645
>  pvr2_hdw_check_firmware drivers/media/usb/pvrusb2/pvrusb2-hdw.c:1812
>  pvr2_hdw_setup_low drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2107
>  pvr2_hdw_setup drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2250
>  pvr2_hdw_initialize+0x548/0x3c10 drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2327
>  pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:118
>  pvr2_context_thread_func+0x361/0x8c0
> drivers/media/usb/pvrusb2/pvrusb2-context.c:167
>  kthread+0x3a1/0x470 kernel/kthread.c:231
>  ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
> Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 ee 82 89 fe 45 89
> e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 40 c0 ea 86 e8 30 1b dc fc <0f>
> ff e9 9b f7 ff ff e8 aa 95 25 fd e9 80 f7 ff ff e8 50 74 f3
> ---[ end trace 6919030503719da6 ]---
> 

-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8

usb/media/pvrusb2: warning in pvr2_send_request_ex/usb_submit_urb

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).

There seems to be no check on endpoint type before submitting bulk urb
in pvr2_send_request_ex().

usb 1-1: New USB device found, idVendor=2040, idProduct=7500
usb 1-1: New USB device strings: Mfr=0, Product=255, SerialNumber=0
usb 1-1: Product: a
gadgetfs: configuration #6
pvrusb2: Hardware description: WinTV HVR-1950 Model 750xx
usb 1-1: BOGUS urb xfer, pipe 3 != type 1
[ cut here ]
WARNING: CPU: 1 PID: 2713 at drivers/usb/core/urb.c:449
usb_submit_urb+0xf8a/0x11d0
Modules linked in:
CPU: 1 PID: 2713 Comm: pvrusb2-context Not tainted
4.14.0-rc1-42251-gebb2c2437d80 #210
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88006b7a18c0 task.stack: 880069978000
RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448
RSP: 0018:88006997f990 EFLAGS: 00010286
RAX: 0029 RBX: 880063661900 RCX: 
RDX: 0029 RSI: 86876d60 RDI: ed000d32ff24
RBP: 88006997fa90 R08: 11000d32fdca R09: 
R10:  R11:  R12: 11000d32ff39
R13: 0001 R14: 0003 R15: 880068bbed68
FS:  () GS:88006c60() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 01032000 CR3: 6a0ff000 CR4: 06f0
Call Trace:
 pvr2_send_request_ex+0xa57/0x1d80 drivers/media/usb/pvrusb2/pvrusb2-hdw.c:3645
 pvr2_hdw_check_firmware drivers/media/usb/pvrusb2/pvrusb2-hdw.c:1812
 pvr2_hdw_setup_low drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2107
 pvr2_hdw_setup drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2250
 pvr2_hdw_initialize+0x548/0x3c10 drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2327
 pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:118
 pvr2_context_thread_func+0x361/0x8c0
drivers/media/usb/pvrusb2/pvrusb2-context.c:167
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 ee 82 89 fe 45 89
e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 40 c0 ea 86 e8 30 1b dc fc <0f>
ff e9 9b f7 ff ff e8 aa 95 25 fd e9 80 f7 ff ff e8 50 74 f3
---[ end trace 6919030503719da6 ]---