A few days ago, news broke that four vulnerabilities were detected in the drivers for Broadcom wireless chips , which allow for remote attacks on devices containing these chips.
In the simplest case, vulnerabilities can be used for remote denial of service, but scenarios where vulnerabilities can be developed that allow an unauthenticated attacker to execute their code with Linux kernel privileges by sending specially crafted packets are not excluded.
These problems were identified during reverse engineering of Broadcom's firmware, where the chips prone to vulnerability are widely used in laptops, smartphones, and various consumer devices, from Smart TVs to IoT devices.
In particular, Broadcom chips are used in the smartphones of manufacturers such as Apple, Samsumg and Huawei.
It is worth noting that Broadcom was notified of the vulnerabilities in September 2018, but took approximately 7 months (i.e., only this month) to release the fixes coordinated with the equipment manufacturers.
What are the detected vulnerabilities?
Two vulnerabilities affect the internal firmware and potentially allow code execution in the operating system environment used in Broadcom chips.
This allows attacking environments that do not use Linux (for example, the possibility of an attack on Apple devices, CVE-2019-8564 is confirmed)).
Here it is important to note that some Broadcom Wi-Fi chips are a specialized processor (ARM Cortex R4 or M3), which will run the similarity of your operating system from implementations of its 802.11 wireless stack (FullMAC).
In these chips, the controller provides the interaction of the main system with the Wi-Fi chip firmware .
In the description of the attack:
To gain full control over the main system after FullMAC is compromised, it is proposed to use additional vulnerabilities or full access to system memory on some chips.
In SoftMAC chips, the 802.11 wireless stack is implemented on the controller side and is run by a system CPU.
In the drivers, the vulnerabilities are manifested in both the proprietary wl driver (SoftMAC and FullMAC) and the open brcmfmac (FullMAC).
In the wl driver, two buffer overflows are detected, exploited when the access point sends specially crafted EAPOL messages during the connection negotiation process (an attack can be performed by connecting to a malicious access point).
In the case of a chip with SoftMAC, the vulnerabilities lead to a compromise of the system kernel, and in the case of FullMAC, the code can run on the firmware side.
In brcmfmac, there is a buffer overflow and an error checking for processed frames, which are exploited by sending control frames. In the Linux kernel, problems in the brcmfmac driver were fixed in February.
Identified vulnerabilities
The four vulnerabilities that were made public since September of last year are now listed under the following CVEs.
CVE-2019-9503
The incorrect behavior of the brcmfmac driver when processing control frames used to interact with the firmware.
If a frame with a firmware event comes from an external source, the controller discards it, but if the event is received through the internal bus, the frame is ignored.
The problem is that events from devices using USB are transmitted through the internal bus, allowing attackers to successfully transfer the firmware that controls the frames in the case of using USB wireless adapters;
CVE-2019-9500
When you activate the "Wake-up on Wireless LAN" function , it can cause an overflow in the brcmfmac controller (function brcmf_wowl_nd_results) by sending a specially modified control frame.
This vulnerability can be used to orchestrate code execution on the main system after chip compromise or in combination.
CVE-2019-9501
The buffer overflow in the wl driver (wlc_wpa_sup_eapol function), which occurs during message processing, the content of the manufacturer information field in which exceeds 32 bytes.
CVE-2019-9502
The buffer overflow in the wl driver (wlc_wpa_plumb_gtk function), which occurs during message processing, the content of the manufacturer information field in which exceeds 164 bytes.
Source: https://blog.quarkslab.com