MMS Not the Only Attack Vector for “Stagefright”

Earlier this week Zimperium zLabs revealed an Android vulnerability which could be used to install malware on a device via a simple multimedia message. This vulnerability, now known as Stagefright, has gained a lot of attention for the potential attacks it can cause. Stagefright makes it possible, for example, for an attacker to install a spyware app in a targets phone without their knowledge just by sending an MMS.

Versions of Android from 4.0.1 to 5.1.1 are affected; this represents 94.1% of all Android devices in use today.

We independently discovered this vulnerability as well; this blog post will disclose more details about this particular flaw.

Vulnerability analysis

Like the previous Android vulnerability we found, this vulnerability is in the mediaserver component, which is responsible for handling open media files.

The version of mediaserver in the vulnerable versions cannot correctly handle a malformed MP4 file. When such a MP4 file is introduced into mediaserver, it may trigger a heap overflow and overwrite data in the heap. This can lead to code execution, which may lead to an app being downloaded onto the device.

The root cause of the vulnerability is an integer overflow when parsing an MP4 file, causing memory to be written out of the buffer. Specifically, it occurs when mediaserver it parses tx3g-flagged data; this is normally used to provide text subtitles.

The affected code can be found in frameworks/av/media/libstagefright/MPEG4Extractor.cpp:

1890         case FOURCC('t', 'x', '3', 'g'):
1891         {
1892             uint32_t type;
1893             const void *data;
1894             size_t size = 0;
1895             if (!mLastTrack->meta->findData(
1896                     kKeyTextFormatData, &type, &data, &size)) {
1897                 size = 0;
1898             }
1899             //For example,fist time chunk_size == 0x100000,second time chunk_size == 0xFFF00001. Then 0x100000 + 0xFFF00001 = 1, allocate 1 byte indeed.
1900             uint8_t *buffer = new (std::nothrow) uint8_t[size + chunk_size];
1901             if (buffer == NULL) {
1902                 return ERROR_MALFORMED;
1903             }
1904
1905             if (size > 0) {
1906                 memcpy(buffer, data, size);//Still writes 0x100000 bytes in 1 byte buffer
1907             }
1908
1909             if ((size_t)(mDataSource->readAt(*offset, buffer + size, chunk_size))
1910                     < chunk_size) {
1911                 delete[] buffer;
1912                 buffer = NULL;
1913
1914                 // advance read pointer so we don't end up reading this again
1915                 *offset += chunk_size;
1916                 return ERROR_IO;
1917             }
1918
1919             mLastTrack->meta->setData(
1920                     kKeyTextFormatData, 0, buffer, size + chunk_size);
1921
1922             delete[] buffer;
1923
1924             *offset += chunk_size;
1925             break;
1926         }

Proof-of-concept demonstration

We tested three scenarios which can be used to attack mediaserver. WE used the adb shell top | grep mediaserver command to the process; we can see that because mediaserver‘s PID (Process Identification Number) changed, the process crashed and restarted.

Scenario #1: Attack from an Application

Here, we demonstrate how this vulnerability can be exploited from within an app. The specially crafted MP4 file will cause mediaserver‘s heap to be destroyed or “exploited”. Here it only crashes, but an attacker can construct a specific data block to fill the heap and gain control of the execution flow.

Figure 1. Debugging output of mediaserver crashes

Scenario #2: Attack from URL

We embedded the same malformed MP4 file (named mp4.mp4) into an HTML file as below, which is then uploaded to a web server. When using the built-in WebView in Android 5.1.1 (as used by the Twitter app) to access the website, the same problems seen in scenario #1 happen.

Figure 2. HTML code for embedding MP4 file

In addition, even though the mobile Chrome browser disables preloading and autoplay of videos embedded with the <video> tag, the malformed file still causes the mediaserver heap overflow. Somehow this limitation has been bypassed.

Scenario #3: Attack from MMS messages

This particular scenario is the one that has received a great deal of attention. We can attach this MP4 file to a MMS and send it to victim’s phone. On our test device (a Nexus 6 running Android 5.1.1), the mediaserver process crashed twice when it received the MMS. This method is particularly dangerous as it involved no user interaction: the mere act of sending the file is sufficient to target the vulnerable device.

Figure 3. Attaching the malformed mp4 file to a MMS message

This vulnerability is fairly potent as it can be effectively controlled by the attacker, which means he can decide when to start the attack and also when to stop. The mediaserver deals with multimedia-related tasks, such as opening and reading MP4 files, decoding/encoding an MPEG4 stream, taking a picture, record the video/audio/screen, read/write pictures and videos from/to the SD card, and so on. An attacker would be able to run their code with the same permissions that mediaserver already has as part of its normal routines.

Users have relatively little recourse to deal with this threat. They may not even be able to detect this threat, given that the initial compromise (the MMS message) doesn’t appear to be malicious in any way. Users can disable the autofetch of MMS content, which will mean that the user will have to open the MMS message before any attack.

A patch has been delivered by Google, but when it will arrive to user devices depends on the device OEMs. In addition, customized Android versions that did not modify mediaserver are also at risk. We will continuously monitor for the existence of new threats that target this vulnerability.

On-device security solutions like Trend Micro Mobile Security can add a layer of protection against threats like these as well.

Disclosure Timeline

We responsibly disclosed this vulnerability to Google, and this is the timeline of our exchanges with them:

May 19: Reported vulnerability to Android Security Team, with a proof-of-concept attack
May 22: Android Security Team assigned ANDROID-21336907, marked it as a High severity vulnerability.
May 26: Android Security Team assigned CVE-2015-3824 to the vulnerability.
July 28: Android Security Team confirmed a fix was available, agreed with Trend Micro on a disclosure schedule.