Angler EK latest CVE-2 0 1 5-8 4 4 6 Flash Exploit analysis-exploit warning-the black bar safety net

2015-12-20T00:00:00
ID MYHACK58:62201570197
Type myhack58
Reporter 佚名
Modified 2015-12-20T00:00:00

Description

Background description

In 1 2 on Adobe mad patch 7 of 8 vulnerability after a week, the abroad security researcher kafeine(@kafeine)broke the Angler Exploit Kit started using this month to patch the CVE-2 0 1 5-8 4 4 6 vulnerability to attack. Our first time to follow up on the vulnerability of the principle and sample of the use of methods for the analysis, here to share with you.

CVE-2 0 1 5-8 4 4 6 – the Supplement had twice the vulnerability

The vulnerability can be described as: Flash in the decoding of the mp3 file in the”ID3” tag of the encoded data, have not been able to properly check the required decode buffer size, resulting in a heap overflow.

Interestingly, this vulnerability has already been patched once, then the number is CVE-2 0 1 5-5 5 6 0 to. At the time this vulnerability has been disclosed the use of:

http://malware.dontneedcoffee.com/2015/08/cve-2015-flash-player-up-to-1800209-and.html

We first look at a problem decoding logic:

ID3 tag can contain the various tag. Some tag can contain encoded text:<http://id3.org/id3v2.3.0>

To TIT tag, for example, when the Flash processing to the TIT tag, will be decoded inside the text. In the TIT tag has a field to indicate the coding of the text size, the following mp3 file, for example:

!

The file contains two TIT tag, which contains the coding text size are 4 bytes and 0x15555556 bytes. When Flash attempts to uncompress the data, dynamically allocated buffer to store the decompressed data,the allocation algorithm is coded according to the different ways there will be a slight difference: the

decode_buffer_size = (encode_data_size – 1) * 6 + 2

Because there can be multiple TIT tag, so you may need multiple decoding process. Each time the decoding, checks the current buffer length is sufficient for decoding, if not, then re-assign the appropriate size:

int current_buffer_size

int decoded_buffer_size

if (current_buffer_size < decoded_buffer_size) {

// HC the decode buffer

}

Below we look at here for the first time out of the question, that is, the CVE-2 0 1 5-5 5 6 0, the report is google project zero, Natalie Silvanovich (@natashenka):

https://code.google.com/p/google-security-research/issues/detail?id=443&can=1&q=flash&start=1 0 0

We look at the decode buffer size calculation formula:

decode_buffer_size = (encode_data_size – 1) * 6 + 2

The relevant code is as follows:

. text:10024F13 loc_10024F13: ; CODE XREF: sub_10024C79+278j

. text:10024F13 mov eax, ebx

. text:10024F15 imul eax, 6

. text:10024F18 add eax, 2

. text:10024F1B cmp [esi+28h], eax

. text:10024F1E mov [ebp+var_20], eax

. text:10024F21 jge short loc_10024F4D

Obviously, when encode_data_size > 0x2aaaaaab, (encode_data_size -1) * 6 + 2 will exceed the 3 2-bit integer range, and get a very small value, resulting in the distribution to decode the array size is not enough to produce overflow.

Adobe is trying to in 1 8. 0. 0. 2 3 2 Version to fix this vulnerability, we see his patch logic:

. text:10024E3E mov eax, [ebp+var_14]

. text:10024E41 imul eax, 6

. text:10024E44 inc eax

. text:10024E45 inc eax

. text:10024E46 cmp eax, [ebp+var_14]

. text:10024E49 jbe loc_10024FB8

This patch for encode_data_size limit, the limit condition is:

(encode_data_size * 6 + 2) > encode_data_size

Think about it know that this patch does not solve this vulnerability, even the integer overflow problems can not solve.\

The easiest bypass the patch method is the use of the following signed integers to compare:

int current_buffer_size

int decoded_text_size

if (current_buffer_size < decoded_text_size) { // Signed Compare !!! ! // HC the decode buffer

}

For example, when encode_data_size=0x15555580,

(0x15555580 – 1) * 6 + 2 = 0x800000FC less than 0

So as long as the current buffer size is a positive number, then the buffer will not be re-allocated, resulting in eventual overflow. This is CVE-2 0 1 5-8 4 4 6 on.

Sample use

We look at the samples in the malicious mp3 file:

!

The sample used is TIT tag, wherein the malicious encode_data_size for 0x15555556, and

(0x15555556 – 1) * 6 + 2 = 0x80000000, just less than 0, You can trigger this vulnerability.

Sample mp3 contains 2 TIT tag, the first encoded data size is 4, and the second is 0x15555556, when dealing with these two tag decoding, the decode buffer allocation process is as follows:

The first tag, size = 0x4:

decode_buffer_size = (4-1) * 6 + 2 = 0x14, allocation of 0x14 bytes of the buffer

The second tag, size=0x15555556:

decode_buffer_size = (0x15555556 – 1) * 6 + 2 = 0x80000000, and the existing buffer size to a signed comparison:

((int)0x80000000 < (int)0x14), the

So the buffer will not be re-assigned, the second decoding data is copied to the 0x14 bytes buffer, causing overflow.

Trojan select the overflow 0x14 is meaningful, 0x14 bytes buffer and finally assigned to the memory block is 0x18 bytes. Just is ByteArray::Buffer size:

class Buffer : public FixedHeapRCObject

{

public:

virtual void destroy();

virtual ~Buffer();

uint8_t* array;

a uint32_t that capacity;

a uint32_t that length;

};

The sample first through a memory layout, allocating a range of the ByteArray object, and then let the decode buffer followed by ByteArray::Buffer object:

[1] [2] next