Exploit the possiblities

Apple AppleBCMWLANCore Driver Heap Overflow

Apple AppleBCMWLANCore Driver Heap Overflow
Posted Sep 21, 2017
Authored by Google Security Research, laginimaineb

There is a heap overflow in Apple's AppleBCMWLANCore driver when handling Completed Firmware Timestamp messages (0x27).

tags | advisory, overflow
systems | apple
advisories | CVE-2017-7103
MD5 | 9e2eb777a0c25de2a642bb1b840b9f64

Apple AppleBCMWLANCore Driver Heap Overflow

Change Mirror Download
Apple: Heap Overflow in AppleBCMWLANCore driver when handling Completed Firmware Timestamp messages (0x27) 

CVE-2017-7103


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. On iOS, the "AppleBCMWLANBusInterfacePCIe" driver is used in order to handle the PCIe interface and low-level communication protocols with the Wi-Fi SoC (also referred to as "dongle"). Similarly, the "AppleBCMWLANCore" driver handles the high-level protocols and the Wi-Fi configuration.

The host and dongle communicate with one another using a set of "message rings". Two of the message rings are used to transfer data from the host to the dongle (H2D). Similarly, the following three rings are used to communicate data back to the host from the dongle (D2H):

-"Control Completion" Ring (Ring #2)
-"TX Completion" Ring (Ring #3)
-"RX Completion" Ring (Ring #4)

As their name implies, the last two rings are used to signal to the host when TX and RX events respectively are completed by the dongle. In contrast, the first ring is used to indicate completion of several "special" control events. Each posted message to this ring has the following structure:

--------------------------------------------------------------------------------------
| Message Type | unused | Flags | unused | Resource ID | Message-Type Dependent Data |
--------------------------------------------------------------------------------------
0 1 2 3 4 6 X

On the iPhone 7 build 14C92, messages posted to the "Control Completion" ring are processed by the "drainControlCompleteRing" function in the AppleBCMWLANBusInterfacePCIe driver. This function goes over each of the posted completion structures, and checks whether they match any of the supported message types. Messages of type 0x27 indicate a completion of a "Firmware Timestamp" request, and are handled by the "completeFirmwareTimestampMsg" function. The completion data for these events has the following structure:

----------------------------------------------------------------------------------------------
| Message Type | unused | Flags | unused | Resource ID | unused | Timestamp Length | unknown |
----------------------------------------------------------------------------------------------
0 1 2 3 4 6 12 14 16

The handler function first performs a lookup using the "Resource ID" in order to locate the buffer associated with the message. Then, the associated buffer is copied to a new "mbuf" chain, and lastly the function calls the "receiveFirmwareTimeSyncMessage" function in the AppleBCMWLANCore driver. Here is the snippet of the corresponding approximate high-level logic:

...
void* resource = find_resource_by_resource_id(..., evt->resource_id);
if (!resource)
return 0xE00002C6;
mbuf_t mbuf;
int64_t res = get_mbuf_from_resource(resource, &mbuf);
if (!res)
return 0xE00002F0;
void* event_data = mbuf_data(mbuf);
mbuf_pkthdr_setlen(mbuf, evt->timestamp_length);
receiveFirmwareTimeSyncMessage(..., evt->unknown, event_data, evt->timestamp_length);
...

Note that the function erroneously fails to verify the "Timestamp Length" field before setting it as the packet header's length.

Regardless, continuing to follow the processing flow, the "receiveFirmwareTimeSyncMessage" function passes the message on to "processFirmwareTimeSyncMessage". At this point since only the pointer to the message's data and the supplied timestamp length field are given to the processing functions, they are unable to verify that the length field is indeed valid (i.e., that it does not exceed the corresponding mbuf's length).

Lastly, let's take a look at the "processFirmwareTimeSyncMessage" function, which performs the following approximate high-level logic:

int64_t processFirmwareTimeSyncMessage(void* this, uint16_t unknown, char* event_data, uint16_t timestamp_length) {

...

if (timestamp_length % 0x1C) {
//Handle error...
}

if (timestamp_length > 0x1B) {

//Validating each TLV
struct timestamp_tlv* tlvs = (struct timestamp_tlv*)event_data;
for (uint64_t i=0; i<(timestamp_length / 0x1C); i++) {
struct timestamp_tlv* tlv = &(tlvs[i]);

if (tlv->tag)
//Handle error...

if (tlv->len != 0x18)
//Handle error...

if (processFirmwareClockInfoTLV(..., tlv, ...) != 0xE3FF8E00)
//Handle error...
}
}

//Copying the result into a buffer
int bytes_left = 2048;
write_current_timestamp_to_buffer(..., result_buffer, &bytes_left);
...
memmove(result_buffer + (2048 - bytes_left), event_data, timestamp_length);
...

}

struct timestamp_tlv {
uint16_t tag;
uint16_t len;
char data[0x18];
};

Where "result_buffer" is a heap-allocated buffer of length 2048.

Since the code above only verifies that each individual firmware timestamp TLV is valid, supplying a large number of valid TLVs will result in the verification stage completing successfully, therefore causing a "memmove" to the "result_buffer" using the attacker-controlled "timestamp_length" field.

Note that several restrictions apply to the data copied in the overflow, namely:
-It must start with the 16-bit tag zero
-It must have a 16-bit length field of 0x18
-It must pass validation by "processFirmwareClockInfoTLV"

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:

November 2017

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