The vulnerable system is bound to a protocol stack, but the attack is limited at the protocol level to a logically adjacent topology. This can mean an attack must be launched from the same shared proximity (e.g., Bluetooth, NFC, or IEEE 802.11) or logical network (e.g., local IP subnet), or from within a secure or otherwise limited administrative domain (e.g., MPLS, secure VPN within an administrative network zone). One example of an Adjacent attack would be an ARP (IPv4) or neighbor discovery flood leading to a denial of service on the local LAN segment (e.g., CVE-2013-6014).
Attack Complexity
High
AC
The successful attack depends on the evasion or circumvention of security-enhancing techniques in place that would otherwise hinder the attack. These include: Evasion of exploit mitigation techniques. The attacker must have additional methods available to bypass security measures in place. For example, circumvention of address space randomization (ASLR) or data execution prevention must be performed for the attack to be successful. Obtaining target-specific secrets. The attacker must gather some target-specific secret before the attack can be successful. A secret is any piece of information that cannot be obtained through any amount of reconnaissance. To obtain the secret the attacker must perform additional attacks or break otherwise secure measures (e.g. knowledge of a secret key may be needed to break a crypto channel). This operation must be performed for each attacked target.
Privileges Required
None
PR
The attacker is unauthenticated prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
User Interaction
None
UI
The vulnerable system can be exploited without interaction from any human user, other than the attacker. Examples include: a remote attacker is able to send packets to a target system a locally authenticated attacker executes code to elevate privileges
Scope
Unchanged
S
An exploited vulnerability can only affect resources managed by the same security authority. In the case of a vulnerability in a virtualized environment, an exploited vulnerability in one guest instance would not affect neighboring guest instances.
Confidentiality
High
C
There is total information disclosure, resulting in all data on the system being revealed to the attacker, or there is a possibility of the attacker gaining control over confidential data.
Integrity
High
I
There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the attacker being able to modify any file on the target system.
Availability
High
A
There is a total shutdown of the affected resource. The attacker can deny access to the system or data, potentially causing significant loss to the organization.
Below is a copy: Broadcom 802.11v WNM Sleep Mode Response Heap Overflow
Broadcom: Heap overflow when handling 802.11v WNM Sleep Mode Response
CVE-2017-7065
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 clients to configure themselves within a wireless network and exchange information about the network topology, peers support an additional set of standards called "Wireless Network Management" (WNM) 802.11v. Much of the information related to WNM is transferred by means of Wi-Fi Action Frames, using the WNM category (10).
One such frame which is handled by Broadcom's firmware is the "WNM Sleep Mode Response" frame, which has following general structure:
---------------------------------------------------------------------------
| Category (10) | Action (17) | Dialog Token | Key Data Length | Key Data |
---------------------------------------------------------------------------
0 1 2 3 5 5 + Key Data Length
(See 802.11-2016, 9.6.14.20 for more information).
On the BCM4355C0 SoC with firmware version 9.44.78.27.0.1.56 the WNM Sleep Mode Response frame is handled by ROM function 0xC8380. 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 verifies that the "Key Data Length" field does not exceed the total frame's length. After performing these verifications, it calls an internal function (ROM 0xC8480) to install the GTK/IGTK. This function has the following approximate high-level logic:
int function_C8480(..., uint8_t* body, int len) {
//Validations
uint8_t ie_len = body[1];
if (!len)
return 0;
if (ie_len + 1 >= len)
return -1;
...
//Handle IGTK
if (body[0] == 1) {
...
}
//Handle GTK
else if (body[0] == 0) {
uint8_t gtk_len = body[4];
if ( ie_len != gtk_len + 11 )
return -1;
function_BC804(..., gtk_len, body + 13, ...);
}
...
}
As shown in the snippet above, the function validates that the length of the GTK in the embedded IE does not exceed the length of the IE itself (plus the metadata). However, the real restriction on the length of the GTK should be much shorter (in fact, I believe the maximal key size in 802.11 is restricted to 32 bytes). This possibly large GTK is then passed to an additional function which copies the GTK into a context structure, before passing it to an addition function in order to actually install the key:
int function_BC804(..., int gtk_len, char* gtk, ...) {
...
context_struct->gtk_len = gtk_len;
...
memcpy(context_struct->gtk, gtk, gtk_len);
return function_C9C14(..., context_struct->gtk, context_struct->gtk_len, ...);
}
int function_C9C14(..., char* gtk, int gtk_len, ...) {
...
char* key_buffer = malloc(164);
...
memcpy(key_buffer + 8, gtk, gtk_len);
...
}
As we can see above, the GTK is eventually copied into a heap buffer of size 164. Due to the validations performed above, the following restrictions apply:
(1) Key Data Length + 5 < Frame Length
(2) IE Length + 11 == GTK Length
Therefore an attacker can set the "Key Data Length" field correctly, set "IE Length" to 255, and set the "GTK Length" to 244. By doing so, the GTK will be copied out of bounds into the heap buffer allocated in function_C9C14, thereby overflowing the heap chunk with attacker controlled data.
I've been able to verify that this code path exists on various different firmware versions, including those present on the iPhone 7, Galaxy S7 Edge and the Nexus 6P.
This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.
Found by: laginimaineb
This information is provided for TESTING and LEGAL RESEARCH purposes only. All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use and Privacy Policy and Impressum