Pages

Sunday, October 14, 2012

Brian Mariani and Frédéric Bourla from High-Tech Bridge SA – www.htbridge.com sent their excellent deep analysis of CVE-2012-1535 vulnerability in Adobe Flash Player. The Word documents with Flash that exploited that vulnerability appeared in August but did not become as popular as RTF CVE-2012-0158, which remains to be the most widely used exploit for targeted email attachments.

The reason for it is that integer overflows are difficult to exploit in general and CVE-2012-1535 is less reliable than other exploits prevalent today. This does not mean it is not in use and I will post several recent samples with this exploit in the next article.
The full analysis is posted below, plus you can download it in PDF format.

Unspecified vulnerability in Adobe Flash Player before 11.3.300.271 on Windows and Mac OS X and before 11.2.202.238 on Linux allows remote attackers to execute arbitrary code or cause a denial of service (application crash) via crafted SWF content, as exploited in the wild in August 2012 with SWF content in a Word document.

ANALYSIS

Slide 02

A FEW WORDS ABOUT FLASH PLAYER

* Adobe Flash is a multimedia platform used to add animation, video, and interactivity to web pages.

* Not all integer overflows are actually exploitable. Many can lead to a denial of service but not always to arbitrary code execution.

* What is true is that very often one could force a program to read or grab an erroneous value and this can contribute to create serious problems into the program’s logic.

* Owing to all these explanations, integer overflows vulnerabilities are relatively difficult to spot and to exploit.

14

HEAP SPRAYING WITH ACTIONSCRIPT

* ActionScript is a programming language used in Adobe Air and Flash.

* Heap spraying is an exploitation technique which consist in placing a specific sequence of bytes at a predictable memory location of the targeted process by allocating chunks of memory. It also provides a way to allocate chunks in the heap area.

* In the CVE-2009-1869 vulnerability a security researcher named Roee Hay used an ActionScript heap spraying in his exploit.

* At line 4 the size of the memory chunk is defined to 0x100000 bytes.

* At line 19, the function doSpray defines a variable named chunk of the

bytearray class.

* The while loop at line 21 will write the second argument using the ascii

character set in the memory chunk.

* Lastly at line 26 a for loop will fill up the memory object with the desired number

of chunks.

* The next slide show the results of this piece of code.

17

THE RESULTS OF HEAPSPRAYING

* Welcome to the 0x0c world!

* Let’s analyze the vulnerability now.

18

VULNERABILITY ANALYSIS (1)

* After triggering a working exploit, the call stack is as described in the image below:

19

VULNERABILITY ANALYSIS (2)

* One can observe that the return addresses start always from the 0x10000000 base memory address.

* This is clearly because we are dealing with a non-aslr (address space layout randomization) windows module.

20

VULNERABILITY ANALYSIS (3)

* At the line 00 it is possible to identify the 0x0c0c0c0b address which confirms that the flow of execution has been successfully hijacked.

21

VULNERABILITY ANALYSIS (4)

* Taking into consideration the last return address in the previous call stack minus ten bytes lets us discover the instruction who gains code execution.

* An EAX pointer seems to allow the attacker to redirect program flow control.

22

VULNERABILITY ANALYSIS (5)

* In order to trace the source of the problem we put a breakpoint at the entry point of the function containing the instruction responsible of triggering the exploit.

* After running the exploit again and breaking at the entry point, the last return address of the call stack tells us about the address 0x104354e4.

23

VULNERABILITY ANALYSIS (6)

* Just before the instruction at the address 0x104354e4 is a call which seems to jump to the function who gets the data from the malformed OTF file.

* We will call this function issue_func.

24

VULNERABILITY ANALYSIS (7)

* According to Rapid7 the code responsible for parsing the OTF file format triggers an exception when the file has a large nTables value contained in the kerning.

* If we refer to the malformed OTF file embedded into the SWF document the ntables value is set to 10000000.

25

VULNERABILITY ANALYSIS (8)

* After Adobe Flash loads the malicious SWF document in memory we can find the malformed OTF format and the crafted data some bytes farther in memory.

26

VULNERABILITY ANALYSIS (9)

* When Adobe Flash parses the OTF file the 10000000 value is passed during the execution of the issue_function.

* The instruction at the address 0x104418C0 reads the large ntable value 10000000.

27

VULNERABILITY ANALYSIS (10)

* Later the instruction SHL EAX, 4 at the address 0x104418c9 logically shifts the EAX register 4 bits to the left.

* This operation converts the EAX register value to ZERO, leading to an integer overflow. The erroneous value is then pushed into the stack at the instruction 0x104418cc.

* In the shifting instruction Adobe Flash does an operation over an invalid value and this is exactly what contributes to create serious problems into the program's logic but more importantly into the memory area.

* The integer overflow corrupts memory in such a way that it is possible to later gain code execution.

28

VULNERABILITY ANALYSIS (11)

* The code continues and reaches a call to a function which will parse the crafted data from the malformed OTF file.

* This function is resolved at the address 0x10442237.

29

VULNERABILITY ANALYSIS (12)

* In the heart of this function, the previously erroneous value pushed into the stack (00000000) will be taken at the instruction 0x10442261.

* When the code reaches this function for the third time the ECX register points to the beginning of the Kern Table.

* At this moment it starts to parse the data with the use of the EAX register as the offset reference.

30

VULNERABILITY ANALYSIS (13)

* At the fifth entry in the function the EAX register will be equal to 8.

* After adding the EAX and ECX registers, ECX will point to the crafted data which will later corrupt the memory.

31

VULNERABILITY ANALYSIS (14)

* At the end of the function EBX and EAX values will be equal to the 1e0cffe8 value.

* This value will be slightly modified and finally written into the memory pointed by the ESI register by four instructions located in the issue_func function.

32

VULNERABILITY ANALYSIS (15)

* Here’s the memory corruption after the code has processed the previously described instructions many times.

33

VULNERABILITY ANALYSIS (16)

* From the issue_func function, the code will push the ESI register and calls the function at the address 0x1044167b.

* This is the function which triggers the payload.

34

VULNERABILITY ANALYSIS (17)

* At this moment the ESI register points to the corrupted memory.

* The EAX register gets the value pointed by ESI at the address 0x10441687.

* Eventually after reaching the CALL instruction the arbitrary code execution is reached.

35

MITIGATE THE RISK

* Updating is the best choice for protecting yourself from this specific threat. [14]

* When this kind of threats is delivered through Microsoft Office documents some mitigations techniques are available, such as:

Malware samples are available for download by any responsible whitehat researcher. By downloading the samples, anyone waives all rights to claim punitive, incidental and consequential damages resulting from mishandling or self-infection.