ignore security and it'll go away

Apple assembleBGScanResults Heap Overflow

Apple assembleBGScanResults Heap Overflow
Posted Sep 22, 2017
Authored by Google Security Research, laginimaineb

There is a heap overflow vulnerability in Apple's assembleBGScanResults when handling ioctl results.

tags | advisory, overflow
systems | apple
advisories | CVE-2017-7105
MD5 | 92a298553ffecc17b336c053ef27d831

Apple assembleBGScanResults Heap Overflow

Change Mirror Download
Apple: Heap overflow in "assembleBGScanResults" when handling ioctl results 

CVE-2017-7105


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.

Along with the regular flow of frames transferred between the host and the dongle, the two communicate with one another via a set of "ioctls" which can be issued to read or write dongle configuration from the host. This information is exchanged using the "Control Completion" ring, rather than the regular "RX" ring.

The "AppleBCMWLANCore" driver performs periodic scans for nearby networks. To do so, the "retrieveBGScanCachedInfo" function issues the WLC_GET_VAR ioctl (262) to read the "pfnbest_bssid" IO-var. Then, after the scan results are collected into a heap-allocated buffer, they are processed by the "assembleBGScanResults" function.

The returned PFN results buffer has the following structure:

-----------------------------------------------------------------------------
| Version | Status | Count (n) | PFN #1 | ... | PFN #n |
-----------------------------------------------------------------------------
0 4 8 12 24 12+(n-1)*12 12+n*12

However, it is important to note that an attacker controlling the dongle can fully control the result of arbitrary ioctl calls. As a result, all ioctl command results should be considered untrusted. For example, on the BCM4355C0 SoC with firmware version 9.44.78.27.0.1.56 (used on the iPhone 7 build 14C92), the "iovar" handling function is located at ROM address 0x4678C, and can be hooked by overwriting its registration pointer at RAM address 0x2068F4.

Assuming an attacker has control over the Wi-Fi dongle, the returned PFN buffer can be arbitrarily crafted. Taking a look at the "assembleBGScanResults" function, we can see that it has the following approximate high-level logic:

int64_t assembleBGScanResults(..., char* results) {
...

uint32_t status = *(uint32_t*)(results + 4);
uint32_t count_pfns = *(uint32_t*)(results + 8);

if (!count_pfns)
return 1;

if (status == 0) {
...

char* copied_pfn_results = IOMalloc((count_pfns * 20) & 0xFFFC);
char* pfn = results + 12;
char local_pfn[20];

for (uint32_t i=0; i < count_pfns; i++, pfn += 12, copied_pfn_results += 20) {

memmove(local_pfn, pfn, 6);
*((int32_t*)(local_pfn + 12) = (int32_t)(pfn[6]);
*((int32_t*)(local_pfn + 16) = (int32_t)(pfn[7]);
memmove(local_pfn + 8, pfn + 10, 2);

memmove(copied_pfn_results, local_pfn, 20);

}
...
}
...
}

(where "results" is the buffer returned by the dongle when reading the IO-Var).

As we can see above, the value "(count_pfns * 20) & 0xFFFC" is used as the length of the allocated buffer, but no check is performed to make sure that this calculation does not result in a truncation of the multiplication. As a result, an attacker can choose the value of the "Count" field so that (count_pfns * 20) & 0xFFFC < count_pfns * 20 (for example, by setting count_pfns to 0x10001). This will cause the copy loop above to copy the contents of the returned IO-Var OOB into the heap allocated buffer, resulting in a heap overflow.

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
    5 Files
  • 17
    Oct 17th
    0 Files
  • 18
    Oct 18th
    0 Files
  • 19
    Oct 19th
    0 Files
  • 20
    Oct 20th
    0 Files
  • 21
    Oct 21st
    0 Files
  • 22
    Oct 22nd
    0 Files
  • 23
    Oct 23rd
    0 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