Vulnerability tracking: Flash serious vulnerability (CVE-2015-0311) detailed technical analysis

Vulnerability tracking: Flash serious vulnerability (CVE-2015-0311) detailed technical analysis
You have a good time with the Flash 0-day vulnerability last week. You need to know why, and sit down and see the cause of this vulnerability when you are tired of playing.

Vulnerability Background: Flash has been exposed to severe security vulnerabilities, affecting all versions of Windows, IE, and FireFox

Last Saturday, Adobe updated the Flash Player software again to fix a 0-day critical vulnerability numbered as a CVE-2015-0311. This vulnerability was submitted by Kafeine, a well-known security researcher.

Attackers exploit this vulnerability to launch drive-by-download attacks on most Windows systems. The vulnerability has been marked as high-risk by the company, which means attackers can execute malicious code, even without the user's knowledge.

This vulnerability is a long-term undisclosed vulnerability in Flash that allows attackers to remotely obtain PC control. Flash versions of Windows, OS X, and Linux contain this vulnerability.

After analyzing the captured samples, we found that the actual Flash file was embedded into a malicious. SWF file that was highly obfuscated. After stripping the obfuscation code, we fully analyzed the vulnerability and found the running method of Exp.

Before introducing the details, share our "mysterious" findings: These code snippets are somewhat similar to the vulnerability exploitation code of CVE-2014-8439. These two vulnerabilities are likely to be exploited by the same hacker.

Vulnerability Source

The analysis found that this is a UAF type vulnerability. In this case, the memory referenced by domainMemory is released, and attackers can read and write the memory and even execute arbitrary code.

To trigger a vulnerability, follow these steps:

Create a ByteArray instance, write a large amount of data, and then compress the instance content.

Figure 1. ByteArray creation code

Overwrite the compressed data of ByteArray from 0 × 200 and assign ByteArray to domainMemory.

Figure 2. Overwrite ByteArray

Extract ByteArray data. The program throws an IOError because of the previous operation. The Code captures an exception and uses another ByteArray to save the released memory address. Then, ByteArray is filled with 0xbbbbbbbbbb.

 

Figure 3. IOError and exception capture

Clear placeholder data in ByteArray.

Figure 4. Release ByteArray memory

Why does domainMemory still reference uncompressed data buffers?

In the AvmPlus project code, we found the vulnerability in the ByteArray: UncompressViaZlibVariant function. The function is designed as follows: first, it allocates a buffer to store uncompressed data. If the decompression succeeds, it notifies domainMemory to use the new buffer. If the decompression fails, it will not notify domainMemory to use the new buffer and release the new requested buffer.

This seems to be beyond review, and a good show is still behind. During the decompression process, the newly allocated buffer will become larger. The class Grower controls the dynamic growth of the buffer. After the growth ends, the class Grower destructor notifies domainMemory to use the extended buffer. In the end, domainMemory uses a new buffer during decompression. If decompression fails, the newly created buffer will be released. This disrupted the logic of the original ByteArray: UncompressViaZlibVariant: Decompression failed, but domainMemory used a new buffer.

This is why domainMemory points to the released memory space filled with 0xbbbbbbbbbb. In this step, Exp can use internal commands to read and write the released memory space.

Figure 5. memory space released for read Operations

 

Similar to most recent Flash Vulnerability exploitation codes, this Exp places the attack vector into the released memory and overwrites the length identifier of the attack vector by controlling the memory layout, this allows you to read and write data to the memory.

 

Figure 6. overwrite memory

Obviously, the memory layout is changed during decompression, and the vector length is also overwritten (SEE ). In my debugging environment, the UAF memory address is 0 × 05120000.

Figure 7. decompressed memory layout (the header information has been decompressed successfully)

Figure 8. 0xbbbbbbbbbb overwrite the memory layout after ByteArray

Figure 9. Memory layout and attack vector after ByteArray release

 

Figure 10. Memory layout after the length of the attack vector is overwritten

After the attack vector length is overwritten to 0 × 40000000, the sample code can read and write the memory at will. The memory capacity is sufficient to execute any code.

Next, Exp only needs to trigger a forged virtual function to complete all the exploitation processes.