thehat Posted February 22, 2016 Report Posted February 22, 2016 Reflecting on Recent iOS and Android Security Updates By zLabsFriday, Feb 12 2016 at 04:00 By: Zuk Avraham, Joshua Drake, Nikias Bassen from ZimperiumzLabs The last thirty days proven to be yet another exciting time for the mobile security ecosystem. Apple and Google released updates for their respective mobile operating systems that fix several critical issues — including some in the kernel that may be exploited remotely. Last Monday, Google released its monthly Nexus security bulletin. We are thrilled to see that the tradition that started after Stagefright’s discovery is a monthly routine now and other vendors are following suit (including Samsung). Blackberry indicated that they are very serious about security issues as well. We welcome Android vendors to reply to the ZHA thread to update the carriers on their plans to release an update addressing the February fixes by Google. We’ll take a closer look at the bulletin and some of the issues fixed later in this post. iOS 9.2.1 In the recent iOS update (9.2.1 – published on January 19th), Apple patched what we initially classified as 7 critical, 3 high, and 2 moderate severity vulnerabilities. These include at least five remotely exploitable vulnerabilities (CVE-2016-1723 through CVE-2016-1727) and at least one critical local kernel vulnerability triggerable from userland with low privileges (CVE-2016-1719). CVE-2015-7995 also appears to be exposed remotely, but determining exploitability will require further investigation. The following graph and table summarize the mentioned issues. CVE Component Impact Severity CVE-2016-1717 DiskImage Kernel Code Execution High CVE-2016-1719 IOHIDFamily Kernel Code Execution Critical CVE-2016-1720 IOKit Kernel Code Execution High CVE-2016-1721 Kernel Kernel Code Execution High CVE-2015-7995 libxslt Remote Code Execution Critical CVE-2016-1722 syslogd Code Execution w/EOP High CVE-2016-1723, CVE-2016-1724, CVE-2016-1725, CVE-2016-1726, CVE-2016-1727 WebKit Remote Code Execution Critical CVE-2016-1728 WebKit CSS Privacy Leak Moderate CVE-2016-1730 WebSheet Privacy Leak Moderate Android The February Nexus Security Bulletin encompasses 10 security issues including 5 critical, 4 high, and 1 moderate severity vulnerabilities. This includes 2 remotely exploitable kernel code execution vulnerabilities (CVE-2016-0801, CVE-2016-0802) and 2 remotely exploitable vulnerabilities exposed through Android’s mediaserver (CVE-2016-0803 in Stagefright, CVE-2016-0804). You can see the bulletin in its entirety here, but the following graph and table summarize the disclosed issues. CVE Component Impact Severity CVE-2016-0801 CVE-2016-0802 Broadcom Wi-Fi Driver Remote Code Execution Critical CVE-2016-0803 CVE-2016-0804 Mediaserver Remote Code Execution Critical CVE-2016-0805 Qualcomm Performance Module Elevation of Privilege Critical CVE-2016-0806 Qualcomm Wi-Fi Driver Elevation of Privilege Critical CVE-2016-0807 Debugger Daemon Elevation of Privilege Critical CVE-2016-0808 Minikin Denial of Service High CVE-2016-0809 Wi-Fi Elevation of Privilege High CVE-2016-0810 Mediaserver Elevation of Privilege High CVE-2016-0811 libmediaplayerservice Information Disclosure High CVE-2016-0812 CVE-2016-0813 Setup Wizard Elevation of Privilege Moderate While privilege escalation issues can be used by local apps or by remote exploits, attackers still need to gain initial code execution on the device to exploit those. With SELinux being enforced more strictly, kernel vulnerabilities are becoming more important (see our 2016 predictions []). Fortunately for the attackers (and unfortunately for us), we suspect that several additional security bugs lurk within Android device specific drivers and kernels. Further, the value of information disclosure vulnerabilities should not be underestimated. For example, CVE-2016-0811 may help attackers defeat security mitigations such as ASLR by leaking address space layout details. Combining several less severe issues together in a chain allows attackers to accomplish full compromise reliably. We expect this practice to remain a trend for the foreseeable future. As promised, Google updated the advisory within 48 hours with links to the AOSP commits that fixed the issues. It’s Interesting that several issues correspond to commits first released to the public in January. Unfortunately, this form of partial disclosure tends to give attackers that monitor code pushes a head start — especially when targeting 3rd party Android devices. On the bright side, that means up-to-date Nexus users were protected for an extra month before the official public disclosure. Let’s take a closer look at the relevant code changes for each issue. Analyzing the bugs The Broadcom Wi-Fi Driver remote kernel code execution vulnerabilities are the most interesting bugs disclosed this month. Although Google did not link to any commits for these two vulnerabilities, the Linux kernel is released under the GNU Public License which requires that source code be made available publicly. Shortly after the release, Security Researcher Ralf Philipp-Weinmann what we believe to be the related commits. The changes most relevant to CVE-2016-0801 and CVE-2016-0802 follow. We performed a cursory analysis of CVE-2016-0802 (full diffhere) and determined that several new validations were added checking packet lengths. However, we were unable to confirm that any ill effects would result from using nefarious values for the now-validated parameters. CVE-2016-0801 tells a different — and quite scary — story. See the following commit details. As you can see, the committer himself declared these issuesexploitable buffer overflows straight away. Looking at the code sheds additional light on the subject. drivers/net/wireless/bcmdhd/wl_cfg80211.c [diff]: In both cases, validation is added to prevent copying more data than the size of the destination buffer. Further, both destination buffers are located on the kernel stack. Because the stack contains crucial items such as the return address and — in the case of the kernel — the thread_info structure, exploiting such overflows is thought to be much easier. The next logical question is if and how these areas of code can be reached by an attacker. The bulletin states, “These vulnerabilities can be triggered when the attacker and the victim are associated with the same network.” However, our quick analysis of the code suggests (unconfirmed) that it may be possible to trigger these vulnerabilities without being associated at all. The following code is responsible for initializing a table of handlers that is used when various events occur. ==== 9765 static void wl_init_event_handler(struct bcm_cfg80211 *cfg) … 9781 cfg->evt_handler[WLC_E_ACTION_FRAME_RX] = wl_notify_rx_mgmt_frame; 9782 cfg->evt_handler[WLC_E_PROBREQ_MSG] = wl_notify_rx_mgmt_frame; 9783 cfg->evt_handler[WLC_E_P2P_PROBREQ_MSG] = wl_notify_rx_mgmt_frame; … 9790 cfg->evt_handler[WLC_E_PFN_NET_FOUND] = wl_notify_pfn_status; ==== The first three presented entries correspond with the first change in the diff. The wl_notify_rx_mgmt_frame function callswl_validate_wps_ie, which contains the buffer overflow. (and also has other callers that have not been investigated). The event IDs (the part in brackets) include probe requests and action frames. This is quite interesting because probe requests are one of the very first packets sent during association. If an Android device enabled the portable hotspot feature, this vulnerability could potentially be exposed to everyone within range of the Wi-Fi radio. The final presented event handler entry deals with scheduled scans. The wl_notify_pfn_status function callswl_notify_sched_scan_results, which contains the buffer overflow. Although we are still investigating, this functionality also sounds a lot like it could expose the vulnerability to any attacker within Wi-Fi range of a vulnerable device. After the Broadcom Wi-Fi driver, the next most interesting vulnerabilities in the bulletin relate to a subject near and dear to our hearts — Android’s media processing. CVE-2016-0803 fixes two integer overflows in libstagefright that were classified as critical RCE. The bugs existed within the SOFTMPEG4Encoder and functions. In both cases, the issue is an integer overflow occurring when dealing with multiplication involving the mWidth and mHeight parameters. This overflow was patched with two commits [] [2] that add a sanitization check prior to allocating 1.5 x mWidth x mHeight bytes in the process’ heap. The relevant changes follow. CVE-2016-0803 affect devices running: Android 4.4.4, 5.0, 5.1.1, 6.0 and 6.0.1 This issue is not without caveats, however. Since it exists within a codec, the victim would need to play back a malicious media file for an attacker trigger the vulnerability. While not all possible ways of accessing media have been investigated, Google Chrome on Android blocks automatic playback of HTML5 video by default (see here). As with most things Android, your mileage may vary depending on the specific device or application dealing with rich media. We encourage developers (especially those working on devices and browsers) to investigate and reconsider the decision to enable auto-play functionality. Another quirk with this vulnerability is that it appears to live within encoder functionality. It’s not presently clear how an attacker would exercise an encoder remotely, but we can’t rule it out either. The other critical RCE, vulnerability in mediaserver that is not related to libstagefright is CVE-2016-0804. It affects devices running Android 5.0, 5.1.1, 6.0 and 6.0.1. It was fixed by re-initializing the mDrmManagerClient member variable to NULL when cleaning up withinNuPlayer::GenericSource::notifyPreparedAndCleanup as shown below. frameworks/av / media/libmediaplayerservice/nuplayer/GenericSource.cpp Fixes of this nature often prevent using stale data later in the lifetime of the process. One of the security researchers on the team of people that reported the issue that this issue was a use-after-free problem triggered when processing a DRM-protected media file. Presumably the attack vector here is media within the browser. It’s not clear if playback is required here, but given the name of the vulnerable function it’s probably not. Conclusions To summarize, both iOS and Android are improving their security from month to month but both OSes still expose users to remotely exploitable bugs. It wouldn’t come as a surprise if more such vulnerabilities were discovered already or in the future. From a preliminary analysis of the bugs, the security of most available devices not running the latest version is alarming. Determined attackers such as professional malware authors and nation states couldn’t be happier with smartphones’ lack of updates and the amount of remotely exploitable vulnerabilities. Sursa: https://blog.zimperium.com/reflecting-on-recent-ios-and-android-security-updates/ 1 1 Quote
