ID

VAR-201704-1558

CVE

CVE-2017-6975

TITLE

Apple iOS Vulnerable to buffer overflow

DESCRIPTION

Wi-Fi in Apple iOS before 10.3.1 does not prevent CVE-2017-6956 stack buffer overflow exploitation via a crafted access point. NOTE: because an operating system could potentially isolate itself from CVE-2017-6956 exploitation without patching Broadcom firmware functions, there is a separate CVE ID for the operating-system behavior. Apple iOS is prone to an arbitrary code-execution vulnerability. An attacker can leverage this issue to execute arbitrary code within the context of the affected application. Failed exploit attempts will likely result in denial-of-service conditions. Versions prior to iOS 10.3.1 are vulnerable. Apple iOS is an operating system developed by Apple (Apple) for mobile devices. Wi-Fi is one of the wireless Internet access components. CVE-2019-8607: Junho Jang and Hanul Choi of LINE Security Team WebKit Available for: macOS Sierra 10.12.6, macOS High Sierra 10.13.6, and included in macOS Mojave 10.14.5 Impact: Processing maliciously crafted web content may lead to arbitrary code execution Description: Multiple memory corruption issues were addressed with improved memory handling. CVE-2019-6237: G. Geshev working with Trend Micro Zero Day Initiative, Liu Long of Qihoo 360 Vulcan Team CVE-2019-8571: 01 working with Trend Micro's Zero Day Initiative CVE-2019-8583: sakura of Tencent Xuanwu Lab, jessica (@babyjess1ca_) of Tencent Keen Lab, and dwfault working at ADLab of Venustech CVE-2019-8584: G. Geshev of MWR Labs working with Trend Micro Zero Day Initiative CVE-2019-8586: an anonymous researcher CVE-2019-8587: G. Geshev working with Trend Micro Zero Day Initiative CVE-2019-8594: Suyoung Lee and Sooel Son of KAIST Web Security & Privacy Lab and HyungSeok Han and Sang Kil Cha of KAIST SoftSec Lab CVE-2019-8595: G. Geshev from MWR Labs working with Trend Micro Zero Day Initiative CVE-2019-8596: Wen Xu of SSLab at Georgia Tech CVE-2019-8597: 01 working with Trend Micro Zero Day Initiative CVE-2019-8601: Fluoroacetate working with Trend Micro's Zero Day Initiative CVE-2019-8608: G. Geshev working with Trend Micro Zero Day Initiative CVE-2019-8609: Wen Xu of SSLab, Georgia Tech CVE-2019-8610: Anonymous working with Trend Micro Zero Day Initiative CVE-2019-8611: Samuel Groß of Google Project Zero CVE-2019-8615: G. Geshev from MWR Labs working with Trend Micro's Zero Day Initiative CVE-2019-8619: Wen Xu of SSLab at Georgia Tech and Hanqing Zhao of Chaitin Security Research Lab CVE-2019-8622: Samuel Groß of Google Project Zero CVE-2019-8623: Samuel Groß of Google Project Zero CVE-2019-8628: Wen Xu of SSLab at Georgia Tech and Hanqing Zhao of Chaitin Security Research Lab Additional recognition Safari We would like to acknowledge Michael Ball of Gradescope by Turnitin for their assistance. Installation note: Safari 12.1.1 may be obtained from the Mac App Store. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 APPLE-SA-2017-04-03-1 iOS 10.3.1 iOS 10.3.1 is now available and addresses the following: Wi-Fi Available for: iPhone 5 and later, iPad 4th generation and later, iPod touch 6th generation and later Impact: Impact: An attacker within range may be able to execute arbitrary code on the Wi-Fi chip Description: A stack buffer overflow was addressed through improved input validation. CVE-2017-6975: Gal Beniamini of Google Project Zero Installation note: This update is available through iTunes and Software Update on your iOS device, and will not appear in your computer's Software Update application, or in the Apple Downloads site. Make sure you have an Internet connection and have installed the latest version of iTunes from www.apple.com/itunes/ iTunes and Software Update on the device will automatically check Apple's update server on its weekly schedule. When an update is detected, it is downloaded and the option to be installed is presented to the user when the iOS device is docked. We recommend applying the update immediately if possible. Selecting Don't Install will present the option the next time you connect your iOS device. The automatic update process may take up to a week depending on the day that iTunes or the device checks for updates. You may manually obtain the update via the Check for Updates button within iTunes, or the Software Update on your device. To check that the iPhone, iPod touch, or iPad has been updated: * Navigate to Settings * Select General * Select About. The version after applying this update will be "10.3.1". Information will also be posted to the Apple Security Updates web site: https://support.apple.com/kb/HT201222 This message is signed with Apple's Product Security PGP key, and details are available at: https://www.apple.com/support/security/pgp/ -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJY4mGWAAoJEIOj74w0bLRGDXMP/2Pxq15u8s/Poib9N4oDn7Y/ 6k+8C8LEz6VmBaFaxKYBbyIGVo9FfLnIUA4Xar8CI2JOz97AifMQBGZra1pXWByL TQ44DgRRyoF4+MckoNPLKaAOy1aSGLF/3m3LEduNaVDZpgIYubzHPU1KaOFMujFw M1e4NEd18+eDgW9c5gXlGHmqtViCGQ1kTi7iySDxHlDd1MguFF9rVDjU2Yfn4juz whYHQKOpcSgkeX0tSRVgOU8UzXfDrzdsP433AqELHq2frBdjbi0B37XclP3dPjsQ MPbQwUE1kbC1agxPfl97RRRFyOyfkI2a1rp9SSFOFqpqIQxkj5gYqx08ji0ol0UF rNC6TZ103Vsyzi9NmO2DO0pv9ocFpg1D2efFkZeUU2hIfdb2B9jnQaulw/WmBzmD KQ3eImhvjTyzfB6UmJm+cdQcWYFYbJBFVeQ20lPeuekckghGLNhU21Zo/HKPnYHD wR8kz0TZUC7uQaiBbB63Blz0T+nNDrkNdTD6VnOhUX9Lpx+cfu717itijduV9L35 iPRDRw9Z8yuN2K0h5SLbHD17NIsNakDDI4VTFBu98YsFJxwHAWqoIH9rdeHbTPwp MQyuwvkQTOAse+e/R+TnfE/xVAAaX6H5P2E5KAuJtO0+mqx89bqn+wF8D2QTtPci qhkKFRDRZJjCDTZijmfA =TCYT -----END PGP SIGNATURE----- . Broadcom: Stack buffer overflow when handling 802.11r (FT) authentication response CVE-2017-6975 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), they first send an authentication request frame. This frame is either sent to the new AP (in over-the-air FT) or to the original AP (in over-the-DS FT). The authentication request frame includes the Fast BSS Transition Information Element (FT-IE) specifying the <a href="https://crrev.com/0" title="" class="" rel="nofollow">R0</a> key holder ID (R0KH-ID) corresponding to the roam request. In response, the AP send back an authentication response frame, also containing an FT-IE. This FT-IE contains the regular fields (Anonce, Snonce, etc.) but also includes the R0KH-ID and R1KH-ID. This is done by encoding the additional fields as TLVs immediately after the structure of the FT-IE (but still within the bounds of the IE), like so: ---------------------------------------------------------------------------- | FT-IE Tag (55) | FT-IE Length | ... FT-IE Contents ... | Additional TLVs | ---------------------------------------------------------------------------- 0 1 2 84 2 + FT-IE Length On the BCM4339 SoC with firmware version 6.37.34.40 the authentication response frame for FT roaming is handled by ROM function 0x7B6A4. This function first retrieves the FT-IE. Then, it allocates a heap buffer for it, using the size specified in the IE's length field. The FT-IE is then stored in the allocated buffer, which is subsequently used to extract the R0KH-ID and R1KH-ID fields. Here is the high-level logic for this function: void function_7B6A4(...) { //Copying in the FT-IE char* ft_ie = bcm_parse_tlvs(auth_frame, auth_frame_len, 55); unsigned short ft_ie_len = ft_ie[1] + 2; char* ft_ie_buffer = malloc(ft_ie_len); memcpy(ft_ie_buffer, ft_ie, ft_ie_len); //Extracting the embedded IEs in the FT-IE. The size of the //FT-IE's fields without the embedded IEs is 84. char* ies = ft_ie_buffer + 84; int ies_length = ft_ie_len - 84; char* r0kh_id = bcm_parse_tlvs(ies, ies_length, 1); char* r1kh_id = bcm_parse_tlvs(ies, ies_length, 3); memcpy(..., ft_ie + 20, 0x20); //Copying the Anonce ... } First, it should be noted that the function erroneously assumes the size of the FT-IE is at least 84. An attacker could include a shorter FT-IE, causing the function to copy 0x20 bytes from (ft_ie + 20), which are stored as the AP's Anonce. Second, after extracting the R0KH-ID and R1KH-ID fields, the function proceeds to calculate the PTK. To do so, the value of PMK-<a href="https://crrev.com/0" title="" class="" rel="nofollow">R0</a> must first be derived. According to IEEE 802.11r-2008 - 8.5.1.5.3, the PMK-<a href="https://crrev.com/0" title="" class="" rel="nofollow">R0</a> is derived as follows: <a href="https://crrev.com/0" title="" class="" rel="nofollow">R0</a>-Key-Data = KDF-384(XXKey, "FT-<a href="https://crrev.com/0" title="" class="" rel="nofollow">R0</a>", SSIDlength || SSID || MDID || R0KHlength || R0KH-ID || S0KH-ID) PMK-<a href="https://crrev.com/0" title="" class="" rel="nofollow">R0</a> = L(<a href="https://crrev.com/0" title="" class="" rel="nofollow">R0</a>-Key-Data, 0, 256) PMK-R0Name-Salt = L(<a href="https://crrev.com/0" title="" class="" rel="nofollow">R0</a>-Key-Data, 256, 128) (see also "wpa_derive_pmk_r0" under <a href="https://w1.fi/cgit/hostap/plain/src/common/wpa_common.c" title="" class="" rel="nofollow">https://w1.fi/cgit/hostap/plain/src/common/wpa_common.c</a>) This calculation is performed by ROM function 0x13C94, which uses the R0KH-ID that was parsed earlier from the FT-IE in the authentication response frame. The function has approximately the following logic: void function_13C94(...) { char buffer[128]; ... memcpy(buffer, "FT-<a href="https://crrev.com/0" title="" class="" rel="nofollow">R0</a>", strlen("FT-<a href="https://crrev.com/0" title="" class="" rel="nofollow">R0</a>")); buffer += strlen("FT-<a href="https://crrev.com/0" title="" class="" rel="nofollow">R0</a>"); memcpy(buffer, &ssid_length, 1); buffer += 1; memcpy(buffer, ssid, ssid_length); buffer += ssid_length; memcpy(buffer, &mdid, 2); buffer += 2; memcpy(buffer, r0kh_id, r0kh_id_len); buffer += rokh_id_len; ... } Where "r0kh_id" is the contents of the R0KH-ID field that was extracted from the FT-IE, and "r0kh_id_len" is the length of the extracted field. Since the R0KH-ID field's length is not validated, an attacker can include an extremely long field within a crafted FT-IE (specifically, the R0KH-ID's length can be at most MAX_IE_SIZE + IE_HEADER_SIZE - FT_IE_SIZE = 255 + 2 - 84 = 173). This would cause the stack-allocated buffer to be overflown, corrupting the stack with attacker-controlled data. 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

IOT TAXONOMY

AFFECTED PRODUCTS

CVSS

PROBLEMTYPE DATA

THREAT TYPE

local

TYPE

buffer error

CONFIGURATIONS

PATCH

EXTERNAL IDS

REFERENCES

CREDITS

Apple

SOURCES

LAST UPDATE DATE

2025-04-20T22:06:21.437000+00:00

SOURCES UPDATE DATE

SOURCES RELEASE DATE