Detailed analysis:
Broadcom produces the 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โ).
When frames are transmitted from the dongle to the host OS on the SDIO interface, they are encapsulated in several additional layers. First, the initial framing is done in hardware by SDPCM, which includes hardware-added headers. Next are the software-added headers, which indicate the logical properties of the data being transmitted (such as the โchannelโ on which the data is transmitted - indicating either data frames or out-of-band responses to ioctls, etc.).
Normally what follows these headers is the actual received frame. However, in certain cases additional information can be added to include metadata about the frame being received, such as information about the TX status, the RSSI value for the frame, etc. When this information is present and WLFC is enabled in the driver, it is parsed and stripped from the sk_buff
, before passing it onto the frame reception handling function, โdhd_rx_frame
โ.
In order to parse the WLFC information, the function โdhd_prot_hdrpullโ is called, which then calls โdhd_wlfc_parse_header_infoโ if WLFC is enabled. This function, in turn, inspects the WLFC information which is encoded in the form of a series of TLVs(see https://android.googlesource.com/kernel/common.git/+/android-3.4/drivers/net/wireless/bcmdhd/include/wlfc_proto. h for more information). In short, each tag represents a different type of WLFC information element, and the length field, whenever the size of the included buffer.
However, most of the included internal functions which handle WLFC information fail to validate length fields. For example, when information with the tag WLFC_CTL_TYPE_HOST_REORDER_RXPKTS is encountered, the โ_dhd_wlfc_reorderinfo_indicateโ function is called, which performs a simply copy operation, like so:
1. static void _dhd_wlfc_reorderinfo_indicate(uint8 *val, uint8 len, uchar *info_buf, uint *info_len) { 2. if (info_len) { 3. if (info_buf) { 4. bcopy(val, info_buf, len); 5. *info_len = len; 6. } 7. else 8. *info_len = 0; 9. } 10. }
Where โlenโ is the length field supplied in the TLV, โvalโ is a pointer to the TLVโs value buffer, and โinfo_lenโ is a pointer to a stack-allocated buffer of size WLHOST_REORDERDATA_TOTLEN
(12) which is allocated in โdhdsdio_readframesโ (or in โdhdsdio_rxglomโ if the frame is glommed).
An attacker controlling the dongle could send a malicious frame containing a TLV with the WLFC_CTL_TYPE_HOST_REORDER_RXPKTS
tag and a length field of 255. Doing so will overflow the stack-allocated buffer with attacker controlled data. Moreover, in order to enable WLFC parsing, the attacker may first craft a special BRCM ethertype packet containing the event โWLC_E_FIFO_CREDIT_MAP
โ. Doing so will cause the โbcmdhdโ driver to call โdhd_wlfc_event
โ in order to handle the event, which in turn will call โdhd_wlfc_enable
โ, thus enabling WLFC parsing on subsequent frames.
Iโve been able to statically verify this issue on the โbcmdhd-3.10โ driver, and in the corresponding โbcmdhdโ driver on the Nexus 5 (hammerhead).