IOS Android security 업데이트 정보

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 [1]).

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 posted what we believe to be the related commits. The changes most relevant to CVE-2016-0801and CVE-2016-0802 follow.

We performed a cursory analysis of CVE-2016-0802 (full diff here) 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 issues exploitable 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 calls wl_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 calls wl_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 SOFTVPXEncoder 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 [1] [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 within NuPlayer::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 stated 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.

- See more at: https://blog.zimperium.com/reflecting-on-recent-ios-and-android-security-updates/#sthash.fSUx2874.dpuf