ignore security and it'll go away

Broadcom 802.11r (FT) Reassociation Response Overflows

Broadcom 802.11r (FT) Reassociation Response Overflows
Posted Sep 26, 2017
Authored by Google Security Research, laginimaineb

Broadcom suffers from multiple overflow vulnerabilities when handling 802.11r (FT) Reassociation Response.

tags | advisory, overflow, vulnerability
advisories | CVE-2017-11121
MD5 | 1e78093fdd782872ab115f5141a79346

Broadcom 802.11r (FT) Reassociation Response Overflows

Change Mirror Download
Broadcom: Multiple overflows when handling 802.11r (FT) Reassociation Response 

CVE-2017-11121


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), allowing a client to roam between APs in the same mobility domain. When a client decides to roam to a different AP in an FT network (in the same mobility domain), it first performs Authentication and then Reassociation.

During the Reassociation process, the client parses the Fast Transition Information Element in order to decrypt and install the embedded GTK. The FT-IE has the following structure:

-----------------------------------------------------------------------
| Tag (55) | Length | MIC CTRL | MIC | Anonce | Snonce | Sub-Elements |
-----------------------------------------------------------------------
0 1 2 4 20 52 84 X

Where each sub-element has the following structure:

---------------------------------------------------------
| Tag | Length | Key Info | Key Length | RSC | Key Data |
---------------------------------------------------------
0 1 2 4 5 13 X


(See 802.11-2016, 9.4.2.48 for more information).

On the BCM4355C0 SoC with firmware version 9.44.78.27.0.1.56 the Fast Transition Reassociation process is handled by ROM function 0x8462C. This function retrieves the FT-IE from the last association response and parses it in order to extract the GTK. Here is the approximate high-level logic
of this function:

int function_8462C(...) {
...

//Getting the FT-IE
uint8_t* ft_ie = bcm_parse_tlvs(..., ..., 55);
if (!ft_ie)
return 0;

//Getting the GTK Sub-Element
uint8_t* gtk_subelem = bcm_parse_tlvs(ft_ie + 84, ft_ie[1] - 82, 2);
if (!gtk_subelem)
return 0;
...

//Decrypting the GTK
context_struct->gtk_length = gtk_subelem[4];
if (!function_6D8(16, ..., gtk_subelem[1] - 11, gtk_subelem + 13, &context_struct->decrypted_gtk)) {

//Installing the GTK
function_C9C14(..., context_struct->decrypted_gtk, context_struct->gtk_length, ...);
...
}
...
}

function_6D8(unsigned key_length, char* key, unsigned input_length, char* input, char* output) {
...
char buf[0x200];
char buf2[0x8];

//Validating the lengths
if ( (key_length - 16) > 16 ||
((0x80808000 << (key_length - 16)) & 0x80000000) == 0 ||
input_length > 0x188 ||
input_length << 29 )
return 1;

//Copying the input into a local stack buffer
memcpy(buf2, input, 8);
memcpy(buf + 8, input + 8, input_length - 8);

//Do AES decryption
...
}

int function_C9C14(..., char* gtk, int gtk_len, ...) {
...
char* key_buffer = malloc(164);
...
memcpy(key_buffer + 8, gtk, gtk_len);
...
}

The function above fails to validate all the length fields in the FT-IE and in the embedded subelement. As a result, an attacker can cause multiple overflows by sending crafted information elements. Here are some possible attacks:

1. The attacker sends a valid FT-IE with an embedded subelement containing a valid length field (gtk_subelem[1]), but with a large crafted value in the key length field (gtk_subelem[4]). Supplying such values will cause the decryption function (0x6D8) to succeed. However, after decrypting the key, function 0xC9C14 will be called in order to install the GTK, using the crafted key length field. Supplying a large value such as 255 in this field will cause the function to copy 255 bytes from the context structure into the heap allocated buffer, whose size is only 164 -- causing a heap overflow.

2. The attacker sends a valid FT-IE with an embedded subelement whose length field (gtk_subelem[1]) is exactly 11. As we can see above, "gtk_subelem[1] - 11" is provided to the decryption function as the "input_length" field. Although the decryption function does perform some validations on the input length field, it fails to ensure that the field is larger than 8. After performing the validations, it calls "memcpy(buf + 8, input + 8, input_length - 8)" in order to copy the input into a stack-allocated buffer. If the input length is zero, "input_length - 8" will underflow, resulting in a large length argument in the memcpy. I'm not sure whether this is exploitable -- if timed correctly, it might be possible to corrupt important values after the stack, such as the global PCIE structure located at the end of RAM, which would allow the attacker to trigger writes into arbitrary locations in the host's memory.

This bug can be addressed by validating the GTK subelement length fields.

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

File Archive:

October 2017

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

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2016 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close