Having fun with Adobe 0-day exploits
We had some time to analyze the latest Adobe Flash 0-day exploit (CVE-2010-1297) floating around on the Internet. By Googling the text inside the file, we found it was generated from a benign SWF file inside the AES.zip file. This might mean that the attacker used the SWF file for dummy fuzzing. We used our custom SWF decoder to perform this SWF diffing operation. The actual difference between the original file and the crashing one is just one byte in the Action Script Byte code (DoABC tag type). The original byte 0x66 was modified to 0x40.
Figure 1: Diffing between original and exploit SWF records
You can look up the AVM2 reference to see what each opcode means. The original opcode 0x66 is "getproperty", while the modified opcode 0x40 means "newfunction".
We also confirmed this code modification by using an SWF decompiler and one of the file diff tools. We used abcdump.exe and a UNIX diff tool to get the following result.
Figure 2: Diffing between decompiled codes
You can see that the original "getproperty" opcode has been changed to the "newfunction" opcode. Basically, this crash or exploit stems from either the SWF file, or a file embedded inside a PDF that contains the DoABC Tag Record with a "newfunction" opcode that has an invalid argument.
With more investigation, the theory we presented previously didn't fit into what we found later. The problem might cause security issues, but this exploit was not activated by that vector. Here's what we got with further analysis.
The shellcode is coming from dynamically generated code in the memory. In the following picture, the ECX register is already contaminated when the call is made.
Figure 3: Contaminated ECX register
If you trace back to where the ECX value is originating, you can find that it's originally from the third argument for the function(dword ptr [ebp+10h]). It's not using the third argument value directly, but there are some indirections with fixed offsets. The problem is that this caller-supplied address contains an invalid address and the pointer value of this address happens to point inside heap-sprayed memory.
Figure 4: Invalid address
We traced back to the caller and checked the third argument for the call. As you can see from the following picture, the third argument is coming from an EBX value in address1BEF0. It goes through an OR operation with 1, which makes the address unaligned. We don't think this is intended, but think this is a kind of opcode generation error that is leading to invalid memory access.
Figure 5: Third argument value
Heap-spray makes a lot of vulnerabilities exploitable that might previously have been thought useless. Code auditors should be more careful in locating this kind of vulnerability.
