Explore the Stagefright vulnerability: POC and EXP

Explore the Stagefright vulnerability: POC and EXP

Preface

In the previous "Discussion on Stagefright vulnerabilities", we have determined the location where the vulnerabilities are generated, and the entire article stops. After all, this vulnerability has a deep impact, and I do not know the details. This article provides a simple solution for exploiting vulnerabilities. Let's just talk about the idea. The specific Exp will be discussed after the specific details of the vulnerability are published.

Teach you how to build a POC

In the previous article, a POC file is provided. Now let's talk about how this file is constructed.

First, prepare an MP4 file. Here, an object is randomly downloaded from the Internet.

Then, add a cover for the mp4 file. The tool used by the author is iTunes. You can add a cover image to the illustration of the introduction.


In the next step, use 010editorto open the blocked poc.mp4 file. Then search for the string "covr ".


Finally, change the first four bytes of "covr" to "00 00 00 01", and the last eight bytes to "00 00 00 01 00 0F"


After saving it, you can open it on your phone. After the mediaserver crashes, it will immediately restart. Therefore, we need system logs to help verify the vulnerability trigger.



The mediaserver can be found through the Log. In fact, this figure also contains other information, which will be discussed later.

Knowing why

To figure out why POC does this, you must start with the source code.

We will continue to read the source code in/frameworks/av/media/libstagefright/MPEG4Extractor. cpp.


As mentioned above, the cause of this vulnerability is chunk_data_size = 0 xFFFFFFFF. So that chunk_data_size + 1 = 0, resulting in the requested Memory Length of 0, and then out-of-bounds writing when copying data to the memory.

Then let's look at how chunk_data_size can be equal to 0 xFFFFFFFF.



The source of Chunk_data_size depends on three values: * offset, chunk_size, and data_offset.



It can be seen from here. * Offset-data_offset = 8. That is to say, chunk_data_size must be equal to 0 xFFFFFFFF. Chunk_size must be equal to 0 xFFFFFFF + 8.

However, we can see that chunk_size reads 4 bytes from * offset for conversion, and the maximum value is 0xFFFFFFFF.
Pay attention to chunk_type. We can see that the value of chunk_type is FOURCC ('C', 'O', 'V', 'R'), that is, (int) 'covr ', this is why the "covr" string is used for positioning.
When I come back and continue reading chunk_size, I find that the type is actually uint64_t, that is, it may be greater than 0 xFFFFFFFF. Continue to read the code.


This section is very clear. If the previously read chunk_size = 1, then the 8 bytes at * offset + 8 will be read as the value of chunk_size, and data_offset will be added with 8.

This can be determined. When the memory value at * offset is set
00 00 00 01 'C' o ''v'' r'00 00 00 01 00 00 00 0F
The chunk_data_size value can be 0xFFFFFFFF to attack!

No Exp. You mean a shovel.

After reading the above content, I believe everyone should know that the POC is still very simple and actually there is no technical content. I believe most people care about Exp. But because it is an unrepaired vulnerability, don't think about it if you want to reach out for Exp. The following describes how to use it. Skip this step if you are not interested.

According to the previous analysis, it can be determined that the vulnerability is caused by off-boundary write of the heap. There is only one idea to use, that is, to modify the values of other objects out of the border, resulting in an error during use or analysis, and jump into the shellcode for execution.

However, the difficulty of this vulnerability is that the attack carrier is a video file, which does not have the ability to execute code, so it cannot interfere with the memory layout or obtain the memory layout information. As a result, it is basically impossible to use it stably. Due to the memory address problem, I have not found any stable method to use it. If you have any, please share it with me!

How to find Exp

In fact, the idea of finding Exp is still relatively simple. From the front "00 00 00 01 00 00 0F", gradually increase the file size, and then continue testing to collect crash information. Find exploitation points.

I was lucky to find a very obvious utilization point without much effort.

Back to the previous crash, let's look at the stack information.


According to the stack, it can be seen that it is an HTTPBase smart pointer and crashes during the analysis.

Wait, android: RefBae: decStrong and android_atomic_dec. I have studied Android vulnerability people before. Do you think you are a little familiar with it? This thing has actually appeared once, in the CVE-2014-7911.

Let's take a look at the implementation of decStrong.


It can be seen that when android_atomic_dec returns 1. A blx R2.

In this article
If (* (offset + 4) = 1 ){
R2 = * (offset + 4) + 8) + 0xC)
Blx r2;
}

Code execution !! Controllable Data !!!

Then we can fill in mp4 to get the following results:


That is to say, for my mp4 file, the file offset value at 0x96a8-4 is the offset mentioned above.

After knowing the offset, You can construct the data for code execution !!!!!

Reality is very skinny

At this point, we found a method to exploit the vulnerability. Although theoretically feasible, it is not so satisfactory in practice.

The main point is that the address written out of the heap is not fixed. Fortunately, after testing, we found that the change was within a certain range. On the Nexus5 mobile phone of the author, the value range is roughly 0xb7000000 ~ Between 0xb9000000. If a large number of tests and adjustments are passed, the coverage is accurate.

Another problem is the execution permission. The memory applied for on the stack does not have the execution permission. Therefore, a stepping stone is required. However, because the attack carrier is only a video file, this is not a simple task.

As for how to write shellcode in the future, there are also some problems.

Of course, these are not the contents of this article.

Summary

In other words, this vulnerability is not fixed. We can only gradually publish the research results based on the situation to avoid adverse effects.

Before the vendor releases an update Patch, let's talk about defense.

To prevent this vulnerability, we recommend that you disable automatic MMS download. However, videos transmitted through any channel may exploit this vulnerability. By sending a video, the recipient cannot determine whether the file is in mp4 format. A hacker may attack the video by clicking play.

At present, most manufacturers are attempting to actively scan and kill video files. However, the author believes that this is a double success, and cannot truly achieve the purpose of defense because it is unable to monitor video files transmitted through all channels.