We have discovered a new vulnerability that allows attackers to perform denial of service (DoS) attacks on Android’s mediaserver program. This causes a device’s system to reboot and drain all its battery life. In more a severe case, where a related malicious app is set to auto-start, the device can be trapped in an endless reboot and rendered unusable.
The vulnerability, CVE-2015-3823, affects Android versions 4.0.1 Jelly Bean to 5.1.1 Lollipop. Around 89% of the Android users (roughly 9 in 10 Android devices active as of June 2015) are affected. However, we have yet to discover active attacks in the wild that exploit this vulnerability.
This discovery comes hot on the heels of two other major vulnerabilities in Android’s media server component that surfaced last week. One can render devices silent while the other, Stagefright, can be used to install malware through a multimedia message.
How it Works
To get inside the device, attackers lure Android device owners to either install a malicious app or go to a malicious site that contains a malformed media file, which ends up in one of the following:
- Once the malformed .MKV file is introduced into mediaserver via the app, the function will fall into an endless loop beyond the user’s control. The whole system will have to slow down until the system reboots or the battery is drained.
- If the user is lured to a malicious site with the .MKV file, the mediaserver function will also enter an endless loop and experience the same issues once the user hits “Play.”
The vulnerability is caused by an integer overflow in parsing .MKV files, which causes the device to fall into an endless loop when reading video frames. The related source codes are shown below:
frameworks/av/media/libstagefright/matroska/MatroskaExtractor.cpp
610 size_t srcOffset = 0;
611 size_t dstOffset = 0;
612 while (srcOffset + mNALSizeLen <= srcSize) {
613 size_t NALsize;
614 switch (mNALSizeLen) {//mNALSizeLen read from mkv file can be 4
615 case 1: NALsize = srcPtr[srcOffset]; break;
616 case 2: NALsize = U16_AT(srcPtr + srcOffset); break;
617 case 3: NALsize = U24_AT(srcPtr + srcOffset); break;
618 case 4: NALsize = U32_AT(srcPtr + srcOffset); break;
619 default:
620 TRESPASS();
621 }
622
623 if (srcOffset + mNALSizeLen + NALsize > srcSize) {
624 break;
625 }
626
627 if (pass == 1) {
628 memcpy(&dstPtr[dstOffset], “\x00\x00\x00\x01″, 4);
629
630 memcpy(&dstPtr[dstOffset + 4],
631 &srcPtr[srcOffset + mNALSizeLen],
632 NALsize);
633 }
634
635 dstOffset += 4; // 0x00 00 00 01
636 dstOffset += NALsize; //when NALsize == 0xfffffffc, endless loop
637
638 srcOffset += mNALSizeLen + NALsize;
639 }
Proof of Concept (PoC)
We created two PoC scenarios to better understand how this flaw works, as follows:
Scenario 1: Attack From Local Application
The first scenario simulates a DoS attack caused by a malicious app (.APK) that uses a malformed .MKV file (filename loop.mkv).
Figure 1. CVE-2015-3823 PoC of DoS attack using a malicious app
The app creates a new mediaserver command every second to play the malformed .MKV file. Even if the user terminates the malicious app, the mediaserver will continue to loop until the system resource or battery is exhausted.
Figure 2. Mediaserver exhausts CPU resource
Scenario 2: Attack From Remote Website
In the second scenario, the malformed .MKV file was embedded into an HTML page. Using the mobile Chrome browser, we opened the webpage and clicked “Play,” prompting the same results as the first scenario.
Figure 3. Source code for the malformed web page
Potential Threat Scenarios
Similar to the Android mediaserver flaws mentioned earlier, this threat comes in using either one of these two methods: a malicious app or a malicious website. Using a malicious app, attackers can easily decide when to start or stop attacks on the device. We already know how this leads devices to reboot and drains batteries. However, in a worst case scenario, the app may be set as an auto-start service that runs every time users open their device, thus not giving them a chance to uninstall it. This endless reboot may render Android devices unusable unless the devices are opened in safe mode and the app is removed.
Getting rid of the app is quite problematic. It may be difficult to locate the app once downloaded. Attackers may opt to keep it hidden and silent for a long time and only trigger the attack days or months later. Users may believe it is not installed and attribute the reboots to problems in the Android system. Devices with customized Android OS but have the same mediaserver program installed are also affected by this threat.
End users can block this threat from the onset by downloading Trend Micro Mobile Security (TMMS), which can detect threats trying to use this vulnerability and running any of the scenarios presented.
We also recommend that device manufacturers patch their systems regularly to prevent their device users suffering from attacks that use this vulnerability.
Disclosure Timeline
This vulnerability was disclosed to Google, with details outlined below:
- May 19: We reported the issue with corresponding POC to the Android Security Team.
- May 21: The Android Security Team accepted it as a moderate severity vulnerability and assigned ANDROID-21335999 for it.
- May 22: The Android Security Team assigned CVE-2015-3823 for it.
- July 31: the Android Security Team confirmed a fix was available and agreed with Trend Micro on a disclosure schedule.