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-0801 and 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.
Follow Zuk Avraham (@ihackbanme)Follow Joshua Drake (@jduck)Follow Nikias Bassen (@pimskeks)
// <![CDATA[
!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+'://platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,fjs);}}(document, 'script', 'twitter-wjs');
// ]]>// <![CDATA[
!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+'://platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,fjs);}}(document, 'script', 'twitter-wjs');
// ]]>// <![CDATA[
!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+'://platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,fjs);}}(document, 'script', 'twitter-wjs');
// ]]>
Android N will bring a cleaner codebase for the mediaserver library (preventing future attacks) as well as sandboxing for various media components to limit an attacker's capabilities.
Microsoft continues its manifest destiny-like drive to pull as many apps as possible onto Windows 10. It announced a Win32/.NET converter called "Project Centennial," Xamarin for mobile dev, and native Bash on Windows.
Many have asked for it, today the first iteration of the vSphere HTML5 Web Client has been delivered through the 
Amazon removed encryption from all of its new devices, which launched last fall, as well as all devices that upgraded to Fire OS 5.
