An unexpected 0-day tour

An unexpected 0-day tour

I don't know if you pay attention to it, before Baidu cloud security X-TEAM written article "Technical Analysis: about Android libStagefright series Vulnerability Analysis", in fact, implies a natural 0 day. This "0 day" is a by-product in the Construction sample.

First, let's look at the original vulnerability: when processing the mpeg tx3g tag, chunk_size is a 64-bit uint, and the sum of size overflows, resulting in a smaller actual proportion of memory. The later memcpy will cause heap overflow, and the written data should be controllable from the file content.

The following code is used:

Platform/frameworks/av/++/android-5.1.1_r8/media/libstagefright/MPEG4Extractor. cpp

 

After understanding the principle, we constructed a POC, which simply changed the "Pleasing" tag: trak in an mp4 file to tx3g, triggering a Memory exception. At that time, I was too busy to continue the analysis without looking into it. After the article is written, I find that this exception is incorrect! Why is there an exception before memcpy?

When IDA is debugged, it turns out that the error here is actually a null pointer error. The exception occurs in the following text: 00063558, R0 = 0, read [R0, #4]. An exception occurs.

 

In the Code layer, when processing the tx3g tag, when calling mLastTrack-> meta-> findData, meta is NULL.

 

The cause is that meta initialization occurs in the tag processing process of the trak. Therefore, modifying the trak to tx3g causes this vulnerability.

 

The code quality of Libstagefright needs to be improved. The POC constructed by the analysis patch can also become a new 0-day! Although it seems difficult to use, please refer to the cumbersome ideas of the following links:

Http://blog.trendmicro.com/trendlabs-security-intelligence/trend-micro-discovers-vulnerability-that-renders-android-devices-silent/

We can also construct a similar webpage to introduce the above mp4. Once a user accesses the following webpage, the screen lock will find that the mobile phone has almost no response and cannot light up the screen:

 

To construct the POC analyzed in the vulnerability of the original libstagefright, follow these steps:

First, make the size> 0. Otherwise, the memcpy process will not be followed. This can be constructed using two tx3g methods. The first tx3g gets the size, and the second tx3g can change the previous size to FFFFFF.

As shown in, there is a trak, followed by two tx3g, the size before the first tx3g is normal, and the size before the second tx3g is FF F0, which causes overflow.

 

The exception is as follows: dlfree has detected heap destruction.

 

Finally, let's give a video that uses the "0-day". It's okay to demonstrate the attack webpage. If an APP is started as soon as it is started, it would be nice to think about it ......