Technical analysis: on the Android libStagefright series vulnerability analysis-vulnerability warning-the black bar safety net

2015-07-31T00:00:00
ID MYHACK58:62201565252
Type myhack58
Reporter 佚名
Modified 2015-07-31T00:00:00

Description

The article corresponds to the CVE-2 0 1 5-{1538,1539,3824,3826,3827,3828,3829}7 a CVE, the specific mapping relationship is currently unknown. The security vulnerability known as the impact of the“9 5%”Android phone security. To follow through on the vulnerability of the attack surface of view, this statement is no exaggeration, the outside world reported on a MMS directly lay the machine argument is also credible. But that was only the many attack surface of an article. Attack surface analysis libStagefright default will be mediaserver, that is to say, if a malicious video file will be mediaserver process, the vulnerability has the opportunity to trigger, for example: Such as file management app, if the video is stored in sdcard, then open the file Manager app, the drop-down list to expose the video, it will trigger a thumbnail analysis, vulnerability trigger the gallery app, click on the local picture will appear in the thumbnail if the video is in sdcard, or the download directory, this time also will trigger. Wechat also affected. Through the micro-channel to send the video, tap will also cause the media server to crash. In addition, the received video even if the user does not click on, followed in wechat send a picture, it will cause the front of the gallery,the file Manager, the same effect will also trigger the thumbnail process and overflow. ! In the latest edition of Chrome43, open a video link mp4, without clicking the auto-trigger ! The boot is also a trigger point, the mediaprovider will scan the sd card all the files, and try to resolve, the grace boot from the start ! media framework architecture is as follows: basically uses the android media framework to develop the program will be affected. ! See here, want to say is, outside the so-called those, turn off the MMS function security and peace also to seek a psychological comfort. From the roots to see the most, with one exception, are and an integer calculation overflow/underflow related, because this problem, indirectly led to the subsequent memory corruption, and other related security issues. Code analysis 1.1.1. No1 heap read out of bounds 1. status_t MPEG4Extractor::parseChunk(off64_t offset, int depth) { 2. a uint32_t that hdr[2]; 3. uint64_t chunk_size = ntohl(hdr[0]); 4. a uint32_t that chunk_type = ntohl(hdr[1]); 5. 6. switch(chunk_type) { Only the following types of chunk_type will trigger the branch parse3GPPMetaData: the 1. case FOURCC('t', 'i', 't', 'l'): 2. case FOURCC('p', 'e', 'r', 'f'): 3. case FOURCC('a', 'u', 't', 'h'): 4. case FOURCC('g', 'n', 'r', 'e'): 5. case FOURCC('a', 'l', 'b', 'm'): 6. case FOURCC('y', 'r', 'r', 'c'): 7. { 8. offset += chunk_size; 9. 1 0. status_t err = style="color: #ff0000;">parse3GPPMetaData(data_offset, chunk_data_size, depth); 1 1. 1 2. if (err != OK) { 1 3. return err; 1 4. } 1 5. 1 6. break; 1 7. } The above parse3GPPMetaData will trigger two 3gp format vulnerabilities. The first setCString heap read out of bounds, first from the file offset read size data to the buffer. status_t MPEG4Extractor::parse3GPPMetaData(off64_t offset, size_t size, int depth) { 1. if (size style="color: #ff0000;">if (mDataSource->readAt( 1 0. style="color: #ff0000;">offset, buffer, size) != (ssize_t)size) { 1 1. delete[] buffer; 1 2. buffer = NULL; 1 3. 1 4. return ERROR_IO; 1 5. } Then, this is similar to strcpy, so that mFileMetaData->setCString(metadataKey, (const char )buffer + 6); https://android.googlesource.com/platform/frameworks/av/+/android-5.1.1_r8/media/libstagefright/MetaData.cpp 1. bool MetaData::setCString(a uint32_t that key, const char value) { 2. return setData(key, TYPE_C_STRING, value, style="color: #ff0000;">strlen(value) + 1); 3. } 1. bool MetaData::setData( 2. a uint32_t that key, a uint32_t that type, const void data, size_t size) { 3. bool overwrote_existing = true; 4. 5. ssize_t i = mItems. indexOfKey(key); 6. if (i Note that the size is dynamic, so it generally will not overflow, but appears to read bounds. 1. void MetaData::typed_data::setData( 2. a uint32_t that type, const void data, size_t size) { 3. clear(); 4. 5. mType = type; 6. style="color: #ff0000;">allocateStorage(size); 7. memcpy(storage(), data, size); 8. } Read the content is saved to a metadata, may leak, such as title, artist these information ! 1.1.2. No2 heap out of bounds write The second one is under flow, if the size 1. if (metadataKey > 0) { 2. bool isUTF8 = true; // Common case 3. char16_t framedata = NULL; 4. int len16 = 0; // Number of UTF-1 6 characters 5. 6. // smallest possible valid UTF-1 6 string w BOM: 0xfe 0xff 0x00 0x00 7. if (size - 6 >= 4) { 8. len16 = ((size- 6) / 2) - 1; // don't include 0x0000 terminator 9. framedata = (char16_t )(buffer + 6); 1 0. if (0xfffe == *framedata) { 1 1. // endianness marker (BOM) doesn't match the host endianness

[1] [2] [3] [4] next