The vulnerable system is not bound to the network stack and the attacker’s path is via read/write/execute capabilities. Either: the attacker exploits the vulnerability by accessing the target system locally (e.g., keyboard, console), or through terminal emulation (e.g., SSH); or the attacker relies on User Interaction by another person to perform actions required to exploit the vulnerability (e.g., using social engineering techniques to trick a legitimate user into opening a malicious document).
Attack Complexity
Low
AC
The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
Privileges Required
Low
PR
The attacker requires privileges that provide basic capabilities that are typically limited to settings and resources owned by a single low-privileged user. Alternatively, an attacker with Low privileges has the ability to access only non-sensitive resources.
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: Apple assembleBGScanResults Heap Overflow
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