Twenty Year Anniversary

Broadcom wldev_ioctl Information Leak

Broadcom wldev_ioctl Information Leak
Posted May 23, 2017
Authored by Google Security Research, laginimaineb

Broadcom suffers from a host to dongle information leak via wldev_ioctl.

tags | advisory
advisories | CVE-2017-0633
MD5 | 4920ccd54f1c8e49e101f7bf4b8b956b

Broadcom wldev_ioctl Information Leak

Change Mirror Download
 Broadcom: Information Leak from Host to Dongle via "wldev_ioctl" 

CVE-2017-0633


Broadcom produces Wi-Fi HardMAC SoCs which are used to handle the PHY and MAC layer processing. These chips are present in both mobile devices and Wi-Fi routers, and are capable of handling many Wi-Fi related events without delegating to the host OS. On Android devices, the "bcmdhd" driver is used in order to communicate with the Wi-Fi SoC (also referred to as "dongle").

Along with the regular flow of frames transferred between the host and the dongle, the two communicate with one another via a set of "ioctls" which can be issued to read or write dongle configuration from the host. This information is exchanged using the SDIO "control" channel (SDPCM_CONTROL_CHANNEL) rather than the regular "data" and "glom" channels (which are used to transfer frames).

When the "bcmdhd" driver wishes to send a ioctl to the dongle, it does so by calling "wldev_ioctl". This function has the following signature:

s32 wldev_ioctl(struct net_device *dev, u32 cmd, void *arg, u32 len, u32 set)

Where "arg" is a pointer to the argument supplied to the ioctl call, and "len" indicates the length of this argument. This function transfers the supplied buffer over SDIO to the dongle, where it is handled by the dongle's ioctl handler function.

The "bcmdhd" driver issues many such ioctls, either when accessing iovars, or when reading and writing configuration used by the dongle. However, in all of these cases, "bcmdhd" neglects to clear the unused memory in the supplied argument buffer before calling "wldev_ioctl". As a result, the buffers transferred via the ioctl calls contain uninitialised memory, including pointers and other information processed by the driver.

To demonstrate this issue, I've located the needed symbols on the Nexus 6P (NUF26K, BCM4358 version 7.112.201.1). The dongle's ioctl handler is at located at ROM address 0x19734, and the pointer to the registered ioctl handler is located in RAM address 0x214BF0. By patching the RAM address to point to a newly allocated code stub, we are able to intercept the ioctl handler on the dongle.

I've written a small code stub which instruments the ioctl handler in order to dump the contents of the buffers passed in by the host. Here's a small sample of these log dumps:

(1237) ioctl - code: 262, length: 512
(1238) 0 : 6f737361
(1239) 4 : 65725f63
(1240) 8 : 65695f71
...
(1404) 148 : ffffffc0
(1405) 152 : 00cdd204
(1406) 156 : ffffffc0
(1407) 160 : 5bd4b6f0
(1408) 164 : ffffffc0
(1409) 168 : 003ee868
(1410) 172 : ffffffc0
(1411) 176 : 5bd4b7e0
(1412) 180 : ffffffc0
(1413) 184 : 5bd4b810
(1414) 188 : ffffffc0
(1415) 192 : 5bd4b790
(1416) 196 : ffffffc0

As can be seen in the log above, the buffer contains multiple pointers from the host's kernel. This issue can be addressed by clearing the unused memory in the passed in argument buffers prior to calling "wldev_ioctl".

This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available, the bug report will become
visible to the public.



Found by: laginimaineb

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

Want To Donate?


Bitcoin: 18PFeCVLwpmaBuQqd5xAYZ8bZdvbyEWMmU

File Archive:

April 2018

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    5 Files
  • 2
    Apr 2nd
    17 Files
  • 3
    Apr 3rd
    11 Files
  • 4
    Apr 4th
    21 Files
  • 5
    Apr 5th
    17 Files
  • 6
    Apr 6th
    12 Files
  • 7
    Apr 7th
    1 Files
  • 8
    Apr 8th
    6 Files
  • 9
    Apr 9th
    21 Files
  • 10
    Apr 10th
    18 Files
  • 11
    Apr 11th
    42 Files
  • 12
    Apr 12th
    7 Files
  • 13
    Apr 13th
    14 Files
  • 14
    Apr 14th
    1 Files
  • 15
    Apr 15th
    1 Files
  • 16
    Apr 16th
    15 Files
  • 17
    Apr 17th
    20 Files
  • 18
    Apr 18th
    24 Files
  • 19
    Apr 19th
    20 Files
  • 20
    Apr 20th
    7 Files
  • 21
    Apr 21st
    10 Files
  • 22
    Apr 22nd
    0 Files
  • 23
    Apr 23rd
    0 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2018 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close