Metaphor-A real life Stagefright exploit analysis

Metaphor-A real life Stagefright exploit analysis
0x00 Summary

This article describes how to use Stagefright, one of the most notorious vulnerabilities in Android. Before that, we thought this vulnerability was very difficult to exploit. In this study, we have made a lot of reference to Google's article-exploit-38226 and the research report Google Project Zero: Stagefrightened.

This article presents our research results, introduces the limitations of this vulnerability in detail, provides a way to bypass ASLR, and provides some research suggestions for future successors.

The vulnerability exploited by the NorthBit team can affect Android 2.2-4.0 and 5.0-5.1 versions. At the same time, it can also bypass ASLR Technology on Android 5.0-5.1 (ASLR is not implemented in Android 2.2-4.0 ).

0x01 Stagefright

Stagefright is a multi-media library in the Android system. It was not until July 27, 2015 that several critical heap overflow vulnerabilities were exposed that people began to notice Stagefright. This vulnerability was first discovered by Joshua Drake of Zimperium. Android versions, from 1.0 to 5.1, are affected.

In the following section, we use "libstagefright" to represent the Stagefright media library and use "stagefright" to represent the corresponding bug.

Although this bug exists in multiple Android versions (nearly 1,000,000,000 devices), many believe that this vulnerability cannot be exploited, this is mainly because the new Android version implements ASLR protection technology.

0x02 Metaphor

Metaphor refers to the use process of Stagefright. In this article, we have studied libstagefright in detail and proposed a new technology that can bypass ASLR. Like the Google team, we used CVE20153864, because this vulnerability is easier to implement than the CVE20151538 vulnerability found by Joshua Drake.

0x03 research objectives

We continue to study this media library because it has been proven to have vulnerabilities (too many bugs and bad code), thousands of affected devices, and various potential attack methods: mms (confidential), SMS (automatic), web browser (rarely or almost no user interaction is required), and so on.

Compared with the efforts of our predecessors, we hope to achieve a more universal and feasible way of using, and feasibility refers to fast, reliable and hard to find-ideally, only use existing vulnerabilities.

All in all, our goal is to bypass ASLR.

0x04 MPEG-4 files

To understand this vulnerability, first understand the MPEG-4 file format. Fortunately, it is not difficult: this file is a collection of TLV (Type-length-value TypeLengthValue) data blocks. In this encoding method, a "type" value specifies the data block type, a "length" value specifies the data length, and a "chunk" value specifies the data itself.

Take MPEG-4 as an example, first encode "length", then "type", and finally "value ". The following pseudo-C describes the block format of the MPEG-4:

When the length is 0, the data continues until the end of the file. The atom field is a short string (also called FourCC) that describes the data block type.

The format is slightly different for types that require more than 2 ^ 32 bytes:

In a tree structure, child data blocks exist in the data of the parent data block.

Describes a media file:

Bug-CVE20153864

This bug has been introduced in many articles, so I will not talk about it here. We use the source code of Android 5.1.0. In special cases, we will explain it again.

This bug in libstagefright appears in the Process of parsing the MPEG-4 file, or, more specifically, parsing the tx3g atom field, which is used to embed Subtitles into the media.

First, let's take a look at the role of this Code:

Quite simple-this code will collect all subtitle data blocks and attach them to a long buffer zone.

Check the size and chunk_size, and under our control, allow us to cause an integer buffer overflow here:

To implement heap overflow, we need at least one valid tx3g data block, which must be used in both integer overflow and heap overflow:

No matter what the actual size of the buffer is allocated, the size bytes in the data part will be written to the buffer.

Note the following when constructing a heap:

Control size-how many bytes are written control data-how much data is written predict where our object will be allocated allocation size under our control Android uses jemalloc as its heap distributor (later)

With this in mind, since we can control the size and data of heap overflow, it is easy to exploit the vulnerability. However, there are many actual restrictions, which complicate the vulnerability exploitation process.

0x05 vulnerability Exploitation

In this section, we introduce the vulnerability exploitation principles and restrictions, as well as some vulnerability exploitation-related discoveries.

Attack path

This vulnerability exists in the media parsing process, that is, the victim's device does not even need to play the media, but only needs to parse it. The media parsing process is used to obtain its metadata, such as the video length, artist name, title, subtitle, and comment.

Finally, we chose to use a web browser. Because JavaScript is required, the advantages and disadvantages of this method are also obvious. You can use the following methods to trick victims into accessing our malicious webpage:

Aggressive websites-can be disguised as "watch all HD online <latest movie>" intrusions into legitimate websites-pages seem legal, but are embedded with hidden content (iframe, hide tags ...) XSS-add malicious content ads to trusted websites-only available here! <Script> or <iframe> tag Drive-by attack free WiFi-a web browser is automatically popped up to open the QR code on the bus station of the portal containing malicious content-scan and download the game while waiting for the bus

The following attack methods do not apply to our methods:

WEB advertisements-"legal" (or illegal) advertisements are used as vulnerability media blogs or forum posts-embedded media MMS-Automatic Acquisition and resolution of live information WhatsApp has been disabled on Android 5.1 +, dating software such as Telegram, Viber, Skype, and Facebook Messenger-vulnerability media introduced by attackers

The victim needs to stay on the attacking webpage for a while. Social engineering may increase the effectiveness of this vulnerability-or other long-term attack methods against victims, such as modifying the home page.

Redirect vtable to heap

Check the vulnerability code again:

The simplest method to use is to build a heap. In this way, the mDataSource object will be allocated immediately after the buffer overflow, and then use this bug to use our vtable (virtual table) overwrite the vtable of mDataSource and set the corresponding readAt entry point to our own memory. This is the implementation method of exploit-38226.

We can completely control the virtual table-redirect any method to any Code address. We need to know or guess our fake vtable address.-Google has proved this is predictable. If we want to find the drop-down chain Gadgets, you Need To Know About libc. so function address-crack ASLRHeap Shaping

To better understand Metaphor and how to bypass ASLR, you need to understand how the Android heap alloc works.

Currently, you only need to know That jemalloc will allocate objects of similar sizes to the same run. The same run contains multiple buffers of the same size, which are called regions. Objects smaller than the fixed region size are rounded up.

For details, see:

Heap Spraying

Heap Spraying is completed using pssh atom. When the parser encounters a pssh data block, the parser allocates a buffer and attaches it to a buffer list:

We can control its size to provide a large value. The limitation of this method is that a media file must contain data of the corresponding size, but we will explain how to overcome this limitation.

Heap Grooming

Heap Grooming is different from Heap Spraying in simple allocation of a large number of objects. By controlling the allocation and release sequence, we can design the sequence of heap objects in a foreseeable way. In exploit-38226, this is implemented using avcC and hvcC data blocks:

(HvcC is basically consistent)

The parser allocates a buffer with a controllable size and passes it to MetaData: setData. MetaData: setData will copy the data to a new buffer and then delete the previous buffer. Of course, the size is under our control.

This method may not be applied on all devices. It may be because the jemalloc configuration is different and two buffers of the same size need to be allocated-one of which is the temporary buffer in MPEG4Extractor: p arse3GPPMetaData, another MetaData object for internal use.

A more universal Heap Grooming method is to use MPEG-4 atoms, pref, auth and gnre. These fields are parsed inside MPEG4Extractor: parse3GPPMetaData:

MetaData: setCString copies a null-terminated string starting with buffer + 6:

We can use chunk_size to control the size of the temporary buffer and the location of the null Byte to control which buffer is actually copied, so that we can allocate the temporary object to another run, it also improves the flexibility of exploits.

Note: Once we add an existing project to MetaData, the old project will be replaced. The MPEG-4 atoms mentioned above provides us with four identical base elements (primitives) for heap control.

To overwrite mDataSource, we need to move it to a location at the bottom of the heap, where we can predict the location of the heap. Like exploit-38226, stbl atom is used to re-allocate mDataSource:

Note that stbl atom allocates a new MPEG4DataSource-because our attack path is through a web browser, the mDataSource type is NuCachedSource2, and NuCachedSource2: flags is:

Heap Grooming is used to overflow the mDataSource:

Ssh atoms is used for Heap Spraying, so that the new Heap will run in the predetermined order. Then, use titl and gnre atoms as placeholders-first assign titl, then assign gnre, release gnre, and then use stbl atom to allocate an MPEG4DataSource.

After titl is released, the data block will be released because tx3g atom will replace its location in the next allocation.

ROP chain Gadgets

We slightly modified the ROP chain proposed by Google in exploit-38226. For example, mmap and memcpy are used to allocate the shellcode. In fact, there is already a buffer address that is known:

We can simply replace the two gadgets with mprotect.

(Note that not all devices use this address)

Google uses a complicated gadgets to pop up a large number of unnecessary parameters from the stack, resulting in a complicated drop-down chain. However, we simply used the pop {pc} and pop {r0, r1, r2, pc} commands.

Like Google Project Zero: Stagefrightened, we use the same stack consumer gadget:

"In this way, we can load most registers, including the stack pointer on r0, which points to the data we control. In this case, you can easily use the drop-down chain to allocate RWX memory, copy it to the shellcode, and then use the functions in libc. so and the gadgets to jump ." (Google Project Zero)

We need to know the following addresses for the remote code execution vulnerability:

Call void function:

Pop {pc}

Call functions with a maximum of three parameters:

Pop {r0, r1, r2, pc}

Replace the stack and call shellcode:

Add r2, r0, #76; 0x4c

Ldm r2, {r4, r5, r6, r7, r8, r9, r10, r11, r12, sp, lr}

...

...

Bx lr

Use mprotect to mark a region as executable and then return:

...

...

Bx lr

We already know the exact size of mDataSource-When overflow occurs, its type is MPEG4DataSource:

IDA shows that the offset of readAt in vtable is 7:

The offset of readAt in bytes is:

The size of MPEG4DataSource and the offset of readAt are the same for all tested devices.

The final drop chain looks like this in the stack, from which we can see which register copies the project:

Other code-specifying vulnerabilities are similar to exploit-38226.

Cracking ASLR

Some device information is required to crack ASLR, because different devices use different configurations-some offset locations or predictable address locations may be modified.

Using the same vulnerability may also obtain arbitrary pointer reading, which may lead to web browser leakage and collect information required to crack ASLR. However, we have limited ability to read memory because of the many restrictions on this vulnerability.

Functions of JavaScript

Because it is an attack through a web browser, we assume that JavaScript can be executed. Metadata encoded in a media file can be used in JavaScript Tags, such as videoWidth, videoHeight, and duration.

We can use the heap overflow vulnerability to overwrite this metadata with a pointer to any memory location, so that any memory can be sent back to the browser and then read through JavaScript.

Return metadata

All MetaData is stored in the MetaData class. This type of media has its own metadata, called mFileMetaData:

And each Track has its own meta field:

Metadata can be returned to the browser only when mInitCheck is set to OK:

MInitCheck can be set only when moov atom is parsed:

This morning, moov data blocks are integrated into media files to ensure that metadata can be returned to the web browser.

Note: This method is not applicable to Android 4.4.4 and earlier versions. The code in these versions seems to only receive moov data blocks that contain the entire file. Otherwise, as long as the "moov" data block ends, NKNOWN_ERROR will be returned. Because of the lack of DRM content, MPEG4's "sidx" and "moof" atoms will terminate the Resolution:

Therefore, this method can only be applied to Android 5.0-5.1.

Returned metadata after Overflow

We cannot repeatedly use the same media file for multiple overflow operations-after the tx3g bug is triggered, the error _ IO cannot be prevented from returning from MPEG4Extractor: parseChunk:

The return value is converted to size_t (32-bit) and compared with chunk_size (comparison)-to realize integer overflow, this value is much greater than 2 ^ 32.

MPEG4Extractor: parseChunk receives a data block offset and a data block depth. This method can parse data blocks and process advance offsets.

For some MPEG-4 atoms, internal data blocks are also recursively parsed. If the parsing is successful, the offset will go forward to the end of the data block.

After a large value is used to cause overflow, we will return the result from tx3g parsing:

We get:

Therefore, if ERROR_IO is returned, all resolutions will stop:

That is to say, we cannot use the same media file for multiple overflow operations.

Terminate process Bypass

When HTTP is used to process video streams, the mDataSource type is NuCachedSource2.mDataSource> NuCachedSource2: readAt specified by readAt triggers the call to NuCachedSource2: readInternal. If the size is too large, mediaserver is terminated:

In case of a failure, CHECK_LE will terminate the process, because the size value needs to be large if the exploitation is successful. Every time we try to exploit a bug, the NuCachedSource2: readInternal check will always fail.

To avoid Process Termination, We need to bypass the NuCachedSource2: readInternal call. By using XMLHttpRequest and responseType = 'blob 'to load media from JavaScript, the browser caches the video to the file system. Using URL. createObjectURL, We can reference cached files as follows:

The URL. createObjectURL function creates a URL to reference the data block in xhr. response.

The following is an example of an object URL:

When Chrome tries to read the "blob" URLs, it is actually accessed as a local resource. We can see files in Chrome cache: ("ls-a" shows hidden files)

Mediaserver does have a descriptor pointing to here: ("ls-l" is followed by a link)

Because this URL points to the file system, mediaserver sets the data source (mDataSource here) to a FileSource class object instead of the NuCachedSource2 class. There is a difference between the two classes. NuCachedSource2 processes HTTP streams and online media caches, while FileSource can perform search and read operations on local files. FileSource: readAt does not use any CHECK_xx macro-that is, we bypassed the Process Termination issue.

Information Leakage

As mentioned above, mediaserver parses the metadata in the media file and sends it to the web browser. MetaData is stored in the MetaData object, and all data is stored in the mltems field of the MetaData object. These fields are actually the FourCC (4-character code) key corresponding to the MetaData: typed_data value:

Typed_data is also in the same file:

If the mSize is greater than 4, ext_data points to the location where data is stored in the memory. Otherwise, the data is stored in the storage. Note that the two are a Union, that is, ext_data and the storage share the same address.

The data of the KeyedVector object is stored in the mStorage field (inherited by the VectorImpl class ):

The content of mStorage is a series of key and MetaData: typed_data elements. In GDB, it looks like this:

For example:

By overwriting the mStorage content, we can overwrite the metadata pointer to point to any location in the memory, so that information can be leaked to the web browser!

Note that as long as the size is greater than 4, it is a pointer, but we can control the size-we can set the size of the metadata field to 4 or smaller, avoid unnecessary metadata fields using pointers. Even if it is a mandatory mime-type field, we can set it to a null termination string (null-terminated) with a size not greater than 4 ).

Because the mSize must be greater than 4, we can only use the duration field to implement Memory leakage-Because duration is an 8-byte length, it is also a pointer. The videoWidth and videoHeight fields are only 4 bytes long, so they cannot be used to leak memory. If you set these fields to greater than 4, the process will be terminated.

KeyedVector Use SortedVector > Store data. When a new value is added to the KeyedVector, the value is inserted to the sorting vector, so that the element order is still sorted by the key.

The following are some original KeyedVector data from a media file with multiple sets of metadata, which is ordered by the key:

We need to know how many metadata elements are inserted before the crash. This is not difficult to do, because we can predict the status of media files by controlling them. When overwriting elements, you do not need to use elements of the same type. You only need to ensure that the order of elements is sorted by the key (as shown above ).

In general, we need to overwrite some 16-byte organizations with sorting elements.

The types of these elements are:

As shown above.

Heap Grooming is also done in a similar way, with the same MPEG-4 atoms (itl, gnre, auth, pref) overflow mDataSource; and with the same Heap Overflow Vulnerability CVE20153864 to achieve coverage.

Before the metadata is returned to the browser, duration will eventually be returned as a string. The following is the longest duration field:

In the end, the time length is converted from 1% seconds to 1‰ seconds, resulting in data loss. Then, we can expose an 8-byte integer to the browser, with an accuracy of + 500.

It is worth noting that the maximum bit filtered by the browser is set to negative, infinite, or NaNs (there are many other representations of these values ). These values are ignored, and the duration field is set to 0.

Note that PRId64 is a signed 64-bit integer. Considering the entire conversion process, the maximum valid values may be:

A higher value overflows to the signature bit, And the browser filters this value because the negative value length (infinite/NaN) is meaningless.

As long as the 23 highest bits are filled with 0 and rounded up to 1000, several BITs are lost. In the end, we can leak 8 bytes. Based on this value, we can get 32 ~ 35 available bits.

ASLR Vulnerabilities

The ASLR Algorithm on 32-bit ARM Linux systems is simple-ASLR will randomly move all modules down several pages, ranging from 0 ~ Page 1. The number of moved pages is called ASLR slide. This value is generated at the process startup and will continue throughout the process cycle.

Then, this value will be passed to mmap_base:

Each module is loaded to its preferred base address and then moved according to ASLR slide. For verification, we ran mediaserver for hundreds of times-recorded the possible address ranges of all modules. Consistent with ASLR randomization, the total address range is 256 pages, and the distance from other modules remains unchanged. Therefore, the ASLR slide of all modules is the same.

Because all modules use the same ASLR slide, we only need to know the base address of one module to know the memory layout of all other modules. As mentioned above, there are only 256 options.

We can use the previously created device version query table to obtain the offset of the gadget. As long as we know the base address of a module, we can translate these gadget offsets into absolute addresses.

Device fingerprint

It is convenient to store all the necessary gadget files in libc. so. Because different devices use different versions of libc. so, the gadget offset also changes. However, in many cases, you can obtain the device fingerprint only based on the User-Agent HTTP header-because the header may contain the device creation version and Android version.

You can build a device version query table to obtain the gadget offset, which eliminates the need to perform some high-cost operations. Finally, to execute remote code, you must first know the base address of libc. so at runtime.

Search for libc. so

Through research/proc/pid/maps, we found that the module location is basically predictable, and its maximum distance is 256 pages. Suppose there is a readable memory part greater than 256 pages (1 MB), we can determine that the maximum possible offset of the preferred base address of the module is 255 pages.

Is an explanation of this concept:

The libicui18n. so module can run because its code is readable and greater than 1 MB:

Note that pages are protected between adjacent parts of some modules (such as text and data). However, we only need a large enough continuous memory area. In this case, the text part is large enough because it has 1,388 pages.

ASLR slide is the preferred base address of the module and the distance between the base address of the runtime:

Therefore:

(Note: aslr moves down)

We know that the ELF header must be a page-specific header. It is strange that the ELF header is located at the beginning of the executable part:

Starting from the preferred base address, every time we move down a page, we finally stop at the ELF header. However, we cannot expose the ELF header, because the maximum limit of this method is 8 bytes. The first eight bytes of the ELF header are:

The following is the maximum leakage limit:

One of the fields is very special, because the highest bit of this field is always 0, so we can leak this field-located on the offset 0x88, The p_memsz and p_flags of the third program header table:

ELF header 0x34 bytes + 0x20 bytes of the first two program header tables + 0x14 bytes of field offset.

ELF File Format and fields of interest are displayed:

The memsz (p_memsz) field in the third program header table conforms to our standard-readable, the module is unique, and the position is fixed.

The following command can dump the ELF header value so that we can find the previously mentioned value:

(Note that this 8-byte value also has p_flags, but this value looks very small and will not exceed the maximum value)

Now, we can create a libicui8n. so p_memsz field query table, each device corresponds to a project.

In this way, when a victim parses a media file, some information is leaked through these fields. To locate the ELF header and fix the gadget offset to the absolute address, the victim must download and parse 256 media files. Because of heap spray, the media files used for code execution may be large enough to make heap spray fall into the predicted address-about 32 MB or larger.

HTTP supports GZIP compressed content. For a 32 MB media file, most of which are filled with 0, we can get a total of 1000 kb of network traffic-nearly times smaller-so that the vulnerability can be exploited.

0x06 Summary

Vulnerabilities are composed of several modules for automatic and real-time vulnerability generation. These modules include:

Crash

Generate small universal media files

This causes mediaserver to crash and reset its status.

Check for vulnerabilities when automatically testing and creating a query table

RCE

Generates a media file based on a specific device. It is used to execute shellcode in the mediaserver.

The query table provides the preferred base address for the gadget offset and libc. so.

Receives the ASLR slide at run time as a parameter and translates the gadget offset into an absolute address.

Leak

Generates a media file based on a specific device to leak memory from the mediaserver process.

Receive an address as a parameter from which data is leaked-this address can be ummapped or protect the page-resulting in a crash

Need to pass The duration field of the tag returns information.

The web browser is required to support XmlHttpRequest of blob response type

The old browser does not support

Supported from Chrome19

Samsung SBrowser is based on Chromium-the earliest version is based on Chromium 18

It has little to do with ROM, and the old browser may not implement ASLR

The following describes the complete vulnerability exploitation process:

0x07 Final requirements

All the methods proposed in this article need to know the victim's device in advance. Even if you can observe the victim's User-Agent header, you cannot understand critical device information, such as the gadget offset or predictable address.

The query table uses the version created by the device to find the information required to exploit the vulnerability. To create a query table, you must:

Libc. so

Extract preferred base address

Extract four necessary gadget items (mentioned in the chapter of the ROP Chain Gadgets)

Pop {pc} pop {r0, r1, r2, pc} stack consumer gadget address mprotect address

Libicui8n. so

Extract preferred base address

Calculate the distance between libc. so

ELF header module identifier

Jemalloc Configuration

Size of jemalloc Region

Can be extracted from libc. so

You can run a test program on the device to obtain these values.

Predictable heap spray address

The optimal heap spray address varies with devices. In reality, different devices may use the same address.

The best choice is to test the device multiple times.

Through further research, it is possible that you do not use a query table to make the vulnerability exploitation more universal.

Note: To find some values, it is best to obtain them through a real device. Libc. so and libicui8n. the so module and jemalloc configurations can be extracted from the ROM system image, but you can guess the predictable heap spray address-but this is not the best practice for some devices.

0x08 Summary

This study proves that this vulnerability can be exploited. However, you must first know the relevant device information in advance, because you need to build a query table based on different ROM.

Our vulnerabilities play the best in Nexus 5 with an earlier version. In addition, we also tested HTC One, LG G3, and Samsung S5. However, when targeting different vendors, the vulnerability utilization is slightly different and some modifications are required.

It is very important that this is a remote code execution vulnerability and you may need to upgrade the mediaserver process permissions because different manufacturers give mediaserver different permissions (refer to/init. rc ).

The libicui8n. so module can be used for at least a few seconds and at most 2 minutes.

In the next section, we propose a more complex method that reduces the utilization time by about four times.

Note:

23.5% of Android devices run Adroid 5.0-5.1-about 235,000,000 devices 4.0% of Android devices run Adroid 2. x-about 40,000,000 devices without ASLR

However, there are already a large number of vulnerabilities on old devices.

By looking at these numbers, it is difficult to determine how many devices are under threat.

Data from: http://www.statista.com/statistics/271774/share-of-android-platforms-on-mobile-devices-with-android-os/

These numbers include a large number of Android tablets, TVs, and watches, but these vulnerabilities exist on all these devices.

0x09 eggs Improves Heap Spray Performance

In exploit-38226, using stbl atom to encapsulate spray data can multiply the heap spray effect. In the NCC Group article, we also mentioned how to further improve the effect. This method can greatly reduce the volume of remote code execution vulnerabilities.

Reduce time consumption

By disclosing different information from the ELF header, You can greatly reduce the number of leaks required. In addition to leaking ELF headers, we can select any address from any memory area containing multiple modules for leakage.

The following example shows a 728 page memory area with 24 ELF headers and only 5 inaccessible vulnerabilities.

(These values are different on different devices.-Here is an example)

We can randomly select an address from this region:

Only five vulnerabilities-only 0.69% of the probability of parsing each media file will cause a crash. We can identify 57 pages-7.83% of the probability of finding ASLR slide when parsing each media file

By comparison, if we rely on speculation, we only have a 256 probability to guess the correct ASLR from page 1.

In this method, the usage takes an average of 5 to 10 seconds between 250 milliseconds and 30 seconds, depending on the number of tags, different devices, running load, and network stability, the most important is the number of attempts to disclose data.

0x0A Study Recommendations

The information leakage method mentioned here cannot be applied in SBrowser-This browser seems to be able to prevent the response type from loading video with blob XmlHttpRequest object; we do not know that this is a security mechanism, or the browser does not support this function.

You can bypass NuCachedSource2: readInternal method CHECK_LE macro:

Use the x-cache-config HTTP header to provide a relatively large value of HighwaterThresholdBytes:

To use the leakage Method on Android 4.4.4, you need to study the DRM content.

</Script>