Vulnerabilities > CVE-2017-11120 - Improper Restriction of Operations within the Bounds of a Memory Buffer vulnerability in multiple products
Attack vector
NETWORK Attack complexity
LOW Privileges required
NONE Confidentiality impact
COMPLETE Integrity impact
COMPLETE Availability impact
COMPLETE Summary
On Broadcom BCM4355C0 Wi-Fi chips 9.44.78.27.0.1.56 and other chips, an attacker can craft a malformed RRM neighbor report frame to trigger an internal buffer overflow in the Wi-Fi firmware, aka B-V2017061204.
Vulnerable Configurations
Common Weakness Enumeration (CWE)
Common Attack Pattern Enumeration and Classification (CAPEC)
- Buffer Overflow via Environment Variables This attack pattern involves causing a buffer overflow through manipulation of environment variables. Once the attacker finds that they can modify an environment variable, they may try to overflow associated buffers. This attack leverages implicit trust often placed in environment variables.
- Overflow Buffers Buffer Overflow attacks target improper or missing bounds checking on buffer operations, typically triggered by input injected by an attacker. As a consequence, an attacker is able to write past the boundaries of allocated buffer regions in memory, causing a program crash or potentially redirection of execution as per the attackers' choice.
- Client-side Injection-induced Buffer Overflow This type of attack exploits a buffer overflow vulnerability in targeted client software through injection of malicious content from a custom-built hostile service.
- Filter Failure through Buffer Overflow In this attack, the idea is to cause an active filter to fail by causing an oversized transaction. An attacker may try to feed overly long input strings to the program in an attempt to overwhelm the filter (by causing a buffer overflow) and hoping that the filter does not fail securely (i.e. the user input is let into the system unfiltered).
- MIME Conversion An attacker exploits a weakness in the MIME conversion routine to cause a buffer overflow and gain control over the mail server machine. The MIME system is designed to allow various different information formats to be interpreted and sent via e-mail. Attack points exist when data are converted to MIME compatible format and back.
Exploit-Db
| file | exploits/ios/remote/42784.txt |
| id | EDB-ID:42784 |
| last seen | 2018-11-30 |
| modified | 2017-09-25 |
| platform | ios |
| port | |
| published | 2017-09-25 |
| reporter | Exploit-DB |
| source | https://www.exploit-db.com/download/42784 |
| title | Apple iOS 10.2 - Broadcom Out-of-Bounds Write when Handling 802.11k Neighbor Report Response |
| type | remote |
Nessus
| NASL family | Misc. |
| NASL id | APPLETV_11.NASL |
| description | According to its banner, the version of Apple TV on the remote device is prior to 11. It is, therefore, affected by multiple vulnerabilities as described in the HT208113 security advisory. Note that only 4th generation models are affected by these vulnerabilities. |
| last seen | 2020-06-01 |
| modified | 2020-06-02 |
| plugin id | 103419 |
| published | 2017-09-22 |
| reporter | This script is Copyright (C) 2017-2019 and is owned by Tenable, Inc. or an Affiliate thereof. |
| source | https://www.tenable.com/plugins/nessus/103419 |
| title | Apple TV < 11 Multiple Vulnerabilities |
| code | |
Seebug
| bulletinFamily | exploit |
| description | 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. In order to allow fast roaming between access points in a wireless network, the Broadcom firmware supports the Fast BSS Transition feature (IEEE 802.11r-2008 FT) as well as the Radio Resource Management standard (IEEE 802.11k-2008 RRM). Much of the information related to RRM is transferred by means of Wi-Fi Action Frames, using the RRM category (5). One such frame which is handled by Broadcom's firmware is the "RRM Neighbor Report Response" frame, which has following general structure: ``` ----------------------------------------------------------------------- | Category (5) | Action (5) | Dialog Token | Neighbor Report Elements | ----------------------------------------------------------------------- 0 1 2 3 X ``` (See 802.11-2016, 9.6.7.7, 9.4.2.37 for more information). On the BCM4355C0 SoC with firmware version 9.44.78.27.0.1.56 the RRM Neighbor Report Response frame is handled by RAM function 0x1B0FE8 (which delegates to ROM function 0xABBBC). This function verifies the dialog token (although that is a single byte field, so it can be easily brute-forced by an attacker if they do not know it in advance). Then, the function copies over the contents of the Neighbor Report Response frame into a heap-allocated buffer and subsequently calls an internal ROM function at 0xAC0A8 to store the number of neighbors for each given "Operating Class" (see 9.4.2.37). Here is the approximate high-level logic for this function: ``` int function_AC0A8(..., uint8_t* nrrep_buffer, ...) { ... //Find and increment neighbor in given channel for given OP-Class int res = function_AC07C(..., nrrep_buffer, ...); //If there's no entry for the given OP-Class, create and populate it if (!res) { uint8_t* buffer = malloc(456); if ( !buffer ) { ... } else { buffer[4] = nrrep_buffer[16]; //Operational Class uint8_t channel_number = nrrep_buffer[17]; //Channel Number uint16_t* chan_neighbor_count_arr = (uint16_t*)(buffer + 6); chan_neighbor_count_arr[channel_number]++; ... } } ... } ``` As shown in the snippet above, the firmware keeps a linked list of buffers, one per "Operational Class". Each buffer is 456 byte long, and keeps the array holding the number of neighbors per channel. The entries have the following structure: ``` ----------------------------------------------------------------------- | Next Pointer | Operational Channel | Padding | Neighbor Count Array | ----------------------------------------------------------------------- 0 4 5 6 456 ``` However, since the "Channel Number" field is not validated, an attacker can arbitrarily provide a large value. While the maximal allowed channel number is 0xE0, by providing a larger value (such as 0xFF), the function above will increment a 16-bit word beyond the bounds of the heap-allocated buffer, thereby performing an OOB write. Note that the same insufficient validation is also present in the internal function 0xAC07C. I've been able to verify that this code path exists on various different firmware versions, including those present on the iPhone 7 and Galaxy S7 Edge. Attaching exploit for this issue. The exploit gains code execution on the Wi-Fi firmware on the iPhone 7. The password for the archive is "rrm_exploit". The exploit has been tested against the Wi-Fi firmware as present on iOS 10.2 (14C92), but should work on all versions of iOS up to 10.3.3 (included). However, some symbols might need to be adjusted for different versions of iOS, see "exploit/symbols.py" for more information. Upon successful execution of the exploit, a backdoor is inserted into the firmware, allowing remote read/write commands to be issued to the firmware via crafted action frames (thus allowing easy remote control over the Wi-Fi chip). The attached archive contains the following directories: ``` -hostapd-2.6 - A modified version of hostapd utilised in the exploit. This version of hostapd is configured to support 802.11k RRM, and in particular Neighbor Reports. Moreover, this version of hostapd is instrumented to add various commands, allowing injection and reception of crafted action frames used throughout the exploit. -exploit - The exploit itself. ``` To run the exploit, you must execute the following steps: ``` -Connect (and enable) a SoftMAC Wi-Fi dongle to your machine (such as the TL-WN722N) -Compile the provided version of hostapd -Modify the "interface" setting under "hostapd-2.6/hostapd/hostapd.conf" to match your interface's name -Configure the following settings under "exploit/conf.py": -HOSTAPD_DIR - The directory of the hostapd binary compiled above -TARGET_MAC - The MAC address of the device being exploited -AP_MAC - The MAC address of your wireless dongle -INTERFACE - The name of the wireless dongle's interface -Assemble the backdoor shellcode by running "exploit/assemble_backdoor.sh" -Run hostapd with the configuration file provided above, broadcasting a Wi-Fi network ("test80211k") -Connect the target device to the network -Run "exploit/attack.py" ``` Following the steps above should result in installation of a simple backdoor allowing read/write access to the firmware. You can interact with the backdoor to gain R/W access to the firmware by calling the "read_dword" and "write_dword" functions, respectively. |
| id | SSV:96597 |
| last seen | 2017-11-19 |
| modified | 2017-09-29 |
| published | 2017-09-29 |
| reporter | Root |
| source | https://www.seebug.org/vuldb/ssvid-96597 |
| title | Broadcom: OOB write when handling 802.11k Neighbor Report Response(CVE-2017-11120) |
The Hacker News
| id | THN:566D208F56BA156CE0E31FFFD218D90A |
| last seen | 2018-01-27 |
| modified | 2017-09-27 |
| published | 2017-09-26 |
| reporter | Mohit Kumar |
| source | https://thehackernews.com/2017/09/apple-iphone-wifi-hacking.html |
| title | Google Researcher Publishes PoC Exploit for Apple iPhone Wi-Fi Chip Hack |
References
- http://packetstormsecurity.com/files/144328/Broadcom-802.11k-Neighbor-Report-Response-Out-Of-Bounds-Write.html
- http://www.securityfocus.com/bid/100984
- https://bugs.chromium.org/p/project-zero/issues/detail?id=1289
- https://lists.apple.com/archives/security-announce/2017/Sep/msg00007.html
- https://lists.apple.com/archives/security-announce/2017/Sep/msg00009.html
- https://source.android.com/security/bulletin/2017-09-01
- https://support.apple.com/en-us/HT208112
- https://support.apple.com/en-us/HT208113
- https://support.apple.com/HT208112
- https://support.apple.com/HT208113
- https://www.exploit-db.com/exploits/42784/