Discussion on Stagefright Vulnerability

Discussion on Stagefright Vulnerability
0x00

Last night, Stagefright reported a major vulnerability, which could cause remote code execution or even sending MMS messages, which may intrude into users' mobile devices. This sounds like a big loophole. As a security personnel, you must take a look at the inside story.

0x01

According to the news, for some reasons, the discoverer of the vulnerability has not published relevant details, but has decided to leave it on BlackHat for further details. That is to say, it is known that the Stagefright inventory of the Android system has a major security problem. What is it? Want to know how to perform Fuzz.

Although, it seems that there is no clue about the details of the vulnerability. However, as a security personnel, the first thing we must firmly believe is that there is no impervious wall in the world! After carefully studying the press release of the vulnerability, we can find that the vulnerability has been submitted to Google and quickly fixed by Google. At the same time, it was found that Google has handed over vulnerability-related information to some partners. After reading this, you can confirm that this vulnerability is still available.

Since Google has fixed this vulnerability in the source code. First, check the submission status of Google's source code.

I simply read the submitted log. I found some fixes for libstagefright security issues, but most of them are concise and difficult to determine.

0x02

It seems that it is not easy to start with Google. Fortunately, Google has handed over the vulnerability-related information to its partners, so we found a message published by CyanogenMod.

That is to say, the vulnerability has been fixed in CM12!

0x03

Then, we found the submission record of CM12 on github.

As you can see, in the recent submission of CM12, all vulnerabilities related to Stagefright are repaired. Based on these fixes, you will have some knowledge about the vulnerabilities!

0x04

We made a simple analysis on some of the repair solutions.

Bug: 20139950

The bug is located in the SampleTable: setSampleToChunkParams function of the frameworks/av/media/libstagefright/SampleTable. cpp file. The bug is described and fixed. It is because the mNumSampleToChunkOffets value is too large and may cause overflow. The related code is as follows:

Note the red line. The access may be out of bounds. This causes security issues.

MSampleToChunkOffset is a member variable of the SampleTable class. It is initialized in SampleTable: setSampleToChunkParams to record data offsets. When mNumSampleToChunkOffsets is set to an invalid value, it will cause readAt to read out of bounds.

According to the current analysis, this vulnerability does not currently cause security attacks. The main reason is that the read data is only used to assign values to member variables. Since data is read from files, the buffer content is actually controllable, because the vulnerability itself has no security significance, just to ensure system stability patch.

Bug: 20139950

This bug is found in the ESDS: parseESDescriptor function of frameworks/av/media/libstagefright/ESDS. cpp. It can be seen from the description and repair code that the variable verification is not strict During the parsing process, which may cause cross-border access. This issue is not important, so I will not elaborate on it.

Bug: 20923261

This vulnerability is generated in the MPEG4Extractor: parseChunk function of frameworks/av/media/libstagefright/MPEG4Extractor. cpp. You can see the full picture of the vulnerability. When chunk_data_size is smaller than kSkipBytesOfDataBox, the red line will become a negative number. Because the last parameter type of setData is size_t, it will be parsed into a large positive number, resulting in errors.

Most of the other vulnerabilities are due to similar causes, and non-strict validation of read data may cause parsing errors. This type of problem generally only causes process crashes and does not cause serious security problems, unless ......

0x05 unexpected

Looking at the examples listed above, it is inevitable that the so-called Stagefright may be alarmist, because most of the vulnerabilities seem to be a small negligence of developers. Until we met TA ......

From the comments submitted, we can see some keywords, such as "potentially exploitable condition ". How is this "condition" produced? It can be seen from the comment that when the chunk_data_size value is SIZE_MAX, it will overflow.

Chunk_data_size is a controllable variable, so the source is not much said. We only focus on the cause of the vulnerability.

In a Linux-like system, SIZE_MAX is generally (size_t)-1), that is, our common 0 xFFFFFFFF (32-bit), when chunk_data_size = SIZE_MAX. The value of chunk_data_size + 1 is 0 (do not ask why =. =), The next code

Because chunk_data_size + 1 = 0, the memory space requested by the buffer is 0.

Then, read the specified content to the memory applied for by the buffer using the mDataSource-> readAt function.

However! The actual applied buffer memory size is 0! That is to say, readAt may cause overwrite and write system data to attack the system !!

As the vulnerability has not been fixed, our article stops here. It is worth mentioning that the same problem occurs more than once in the same file.

For more details, let's start exploring them.

0x06 Summary

Due to limited time, this article only analyzes the possible attack points from the perspective of patch. After all, this vulnerability has a huge impact and has not yet been fixed. Therefore, it is not recommended to publish more details. In some cases, I hope to understand it.

An overview of all the repair code and the cause of the vulnerability are all due to the complete data verification. Only Stagefright was exposed. Considering that the Android system contains a large number of file parsing code, including image, compressed package, audio, video, and other decoding libraries. Have these databases strictly verified the data during File Parsing? Will there be another serious bug in audio decoding tomorrow? This should be a question worthy of consideration by developers and security practitioners.

0x07 postscript

This vulnerability should not be too detailed, so the previous description is too vague and inaccurate in many places. This caused some questions.

Put a POC at last. Opening the file will cause parsing errors. Because parsing errors alone cannot prove that the vulnerability was triggered, some logs were added as auxiliary evidence.

The key point is that the buffer points to the address 0xb8a93fe0, but the size is 0. The content of the buffer pointing to the address is "F0 31 EC B6", which is replaced with "12 34 56 78" and the overwrite length is "x = 0x40020 ".

Users who are familiar with the details can also find relevant modifications in the mp4 file.

Finally, this mp4 file comes from the network, 10 + M size, mp4 format ...... To learn more about the vulnerability, you can fix the mp4 file and view its content. (You understand =. =)