The Root Cause Analysis of Flash 0day CVE-2018-5002 Exploit

The Overview

Tencent Enterprise Security (https://s.tencent.com/) discovered a large-scale attack using the Flash 0day vulnerability in the wild on June and we soon reported this attack to Adobe. Later after Adobe affirmed the vulnerability, we published an article about the detailed procedure of how the APT organization uses the Flash 0day to generate crafted excel files to launch attack against targeted countries and regions. Here is the link of this report Tencent Enterprise Security Detects Flash 0day Attack In The Wild.

Adobe has released security updates to address critical vulnerabilities including CVE-2018-5002 on June 7. All versions of Flash Player before 30.0.0.113 are affected.

Attack Procedure

From the attack we observed, we found that the carrier this unknown APT organization uses is an excel file with a tempting name basic_salary.xlsx. A crafted SWF file is embedded into this excel file. The excel file is written in Arabic and its content is about the salary of officers in the Foreign Ministry.

The complete attack procedure is as following.

From a website, the SWF object SWF1 in this excel file downloads another encrypted SWF file SWF2 with the exploit code of CVE-2018-5002. From the same website, SWF1 then get a dynamical key to decrypt SWF2. Therefore, SWF2 could download encrypted payloads, decrypt them and execute the decrypted payloads once the exploit runs successfully. 

Vulnerability

The vulnerability CVE-2018-5002 lies on the incorrect computation of handle-crafted SWF files, which helps an attacker execute arbitrary code remote. The exploit of this vulnerability only needs simple memory layout without complex heap spray operations.  

Root Cause Analysis

Notice the following analysis environment is Windows 7 X86 with Flash Player 29.0.0.171.

In order to use domain memory to get faster read/write access of the memory, the ActionScript compiler(ASC2) brings in special memory opcodes needed to use domain memory. These opcodes such as li8, si8 are encapsulated as some APIS in the avm2.intrinsics.memory package. These APIS are listed in the following screenshot. This vulnerability is related to illegal use of these APIS.

The sample code is obfuscated in purpose. After wiping out those obfuscation, we locate the vulnerability code as following. The left is the decompiled code and the bytecodes lie in the right.

The Static Initializer code in the red box isn’t decompiled entirely. To get a better understanding of the vulnerability, we make pseudo codes based on the right opcodes.

When we debug the vulnerability code, the execution of li8 opcode throws an exception and the exception is handled by the current catch block. In the catch block, these opcodes exchange two object pointers (local_448, local_449) out of this method range,and they could make type confusions. There are two important questions which drive us to dig the root cause of the vulnerability out.

( I ) Who should handle the exception?

The li8 opcode lies in the label ofs0024 while the try block starts from the label ofs0000 to the label ofs0004, which means li8 opcode isn’t in the scope of this try block. Therefore, the catch block shouldn’t handle the exception throwed by li8. But the fact goes against this speculation.

( II ) Why do codes in the catch block can read/write out of range?

The local count of this block is 2 so only local_0 and local_1 can be accessed in this method. However, the codes in the catch block can access local_448 and local_449 out of range.

Now we try to find out the answers of these two questions one by one.

Exception Handling

While we debug the AVM (ActionScript Virtual Machine) of Flash and read the source code of the AVM, we know that the AVM will save the current PC (Program Counter) into a variable called it EX_PC before the execution of bytecodes which may throw an exception. When some exceptions occur, the AVM uses EX_PC to search for the related exception handler (the catch block in the ActionScript or bytecodes) in the ExceptionHandlerTable.

In this case, the AVM will first check whether the offset parameter of li8 opcode exceed the range of domain memory before the execution of li8 opcode. The initialized size of domain memory is 0x400 bytes, which is 1024 bytes in decimal. The next is the initialization code of domain memory.

Here, the offset parameter of li8 opcode is 123456 which is much bigger than 1023. So the AVM throws a RangeError exception. The related code is as following, in which 0x34 is the value of li8 opcode 0x35 minus 1.

At the start of this block, the AVM initializes EX_PC to 0, which is the offset of the first bytecode jump in the block. Then three bytecodes, jump, push, li8 are executed but none of them saves the current PC into EX_PC. Hence, when the AVM receives the Range Error exception throwed by li8 bytecode, it believes the exception was caused by the bytecode at offset 0. Then it calls the FindExceptionHandler function to find out the exception handler according to the EX_PC value. The EX_PC 0 is just in the current try block so the FindExceptionHandler returns the current catch block as the right handler.

The explanation is proved by the debug info of this vulnerability as next. The second parameter of the FindExceptionHandler function is 0, which is just the EX_PC.

Read/write out of range

The catch block could read/write out of range because it confuses the AVM to bypass its verification.

First the AVM tries to verify the try block, there is only one jump bytecode and the jump bytecode is taken as bytecodes throwing no exceptions.

Meanwhile, the target of the jump bytecode isn’t in the try scope. So the AVM takes the whole method as non-exception one and the catch block will never be executed. As a result, the AVM skips the verification of the catch block and the code in the catch block can read/write out of range.

The memory layout before out of range. There are 256 custom objects on the stack. No 1, 3, 5… 255 are custom object of type A while the remaining are custom objects of type B.

Trigger the vulnerability and finish exchange of custom object A and custom object B:

In the end, the type confusion is achieved and the ability to read/write arbitrary address can be realized.

Detection AND Defense

Tencent Enterprise Security (https://s.tencent.com/) estimates the exploit will be mainly hold by the forceful APT organizations before the exploit details start to spread into a wide range. Since there are a lot of computers installed Adobe Flash Player and many users may not update to the latest version in time, it will bring a great threaten such as webpages linked to trojan when the vulnerability is used by the virus writers.

The security experts of Tencent Enterprise Security (https://s.tencent.com/)strongly recommend users to update Adobe Flash Player to the latest 30.0.0.113. Here is the official download address https://get.adobe.com/cn/flashplayer/.

Tencent Enterprise Security (https://s.tencent.com/) reminds the government agencies, the enterprises, users not to open the documents from unknown sources and install the secure software to defense such attack.

References

Tencent Enterprise Security Detects Flash 0day Attack In The Wild

Adobe Security Bulletin(APSB18-19)

https://helpx.adobe.com/security/products/flash-player/apsb18-19.html