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.
The full analysis is posted below, plus you can download it in PDF format.
Download the full paper (slides) in PDF format here
http://contagio.deependresearch.org/docs/CVE-2012-1535-Adobe-Flash-Player-Integer-Overflow-Vulnerability-Analysis.pdf
Download files for analysis:
http://contagiodump.blogspot.com/2012/08/cve-2012-1535-samples-and-info.html
---------------------------------------------------------------------------------------------------
Previous papers by the same authors
- CVE-2012-1889 Security Update Analysis - Analysis video and presentation from High-Tech Bridge by Brian Mariani and Frédéric Bourla
- CVE-2012-1889 Microsoft XML vulnerability - Samples and Analysis by Brian Mariani and Frédéric Bourla
CVE #
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.
* Flash manipulates vectors and graphics to provide animation of text, drawings
and images.
* It supports bidirectional streaming of audio and video.
* It can capture user inputs via mouse, keyboard, microphone and camera.
* Flash contains an object-oriented language called ActionScript.
* It supports automation via the JavaScript Flash language.
03
ADOBE FLASH PLAYER HISTORY
* Flash originated with the application SmartSketch, developed by Jonathan Gay.
* It was published by FutureWave Software, which was founded by Charlie
Jackson, Jonathan Gay and Michelle Welsh.
* As the Internet became more popular, FutureWave added cell animation editing to the vector drawing capabilities of SmartSketch and released FutureSplash Animator on multiple platforms.
* FutureWave approached Adobe Systems with an offer to sell them FutureSplash in 1995, but Adobe turned them down at that time.
* In 1996, FutureSplash was acquired by Macromedia and released as Flash, contracting "Future" and "Splash".
* Flash is currently developed and distributed by Adobe Systems, as the result of their purchase of Macromedia in 2005.
04
FLASH IS NOT AN EXCEPTION
* Just as other widespread software Adobe Flash Player has been heavily audited by cybercriminals the last years.
* Their main objective is to find high-risk security vulnerabilities which does almost not need user's interactivity in order to fully compromise a remote system.
* Since 2006 Adobe Flash security problems have raised considerably.
* Tens of vulnerabilities have been reported the last year.
* The following slides confirms this issue by giving an overview of Adobe Flash Player vulnerabilities reported between 2006 and 2011.
05
SOME STATISTICS
Reported vulnerabilities in Adobe Flash Player
06
SOME BAD NEWS ABOUT FLASH PLAYER
07
TIMELINE OF THE CVE 2012-1535
* In this document we will be focused in a pretty recent Adobe Flash Player
vulnerability tagged as CVE-2012-1535 by Mitre.
* Before the 14th August 2012 the flaw was seriously abused over Internet and mainly distributed through malicious Microsoft Word documents. [2] [4]
* On 14th August 2012 Adobe has finally released a patch. [2]
* On August 15th 2012 Alien Vault Labs [4] has published a brief analysis based on a malicious Microsoft Office Word documents with an embedded SWF file.
* The 17th August 2012 Mila Parkour from Contagiodump [3] has posted some of these samples.
* Finally, the 17th August 2012 Rapid7 has published a working exploit for IE 6/7 and 8 on Windows XP SP3 and finally updated the exploit for IE 9 on Windows 7 SP1.
08
SAMPLES FROM CONTAGIODUMP (1)
* Mila Parkour provided us with some of the aforementioned samples in order to dig about this vulnerability.
* These ones are Microsoft Word documents with an embedded SWF document.
* After a trivial analysis one can easily understand that these files contain suspicious data.
* There is enough doubtful information to realize that they were intended to launch a client side exploit in Adobe Flash Player.
* The following slides show some key information found in the sample “7E3770351AED43FD6C5CAB8E06DC0300-iPhone 5 Battery.doc.”
09
SAMPLES FROM CONTAGIODUMP (2)
* The Shockwave Flash object is easily identifiable.
10
SAMPLES FROM CONTAGIODUMP (3)
* The ActionScript heapspray code and the payload can definitely be recognized.
11
SAMPLES FROM CONTAGIODUMP (4)
* Eventually a strange font description named “Pspop” can be found embedded into the SWF document.
12
VULNERABILITY DETAILS
* The flaw relies on the ActiveX component of Adobe Flash Player before version 11.3.300.271.
* The code responsible for parsing the OTF file format (OpenType Format) triggers an exception when the file has a large nTables value contained in the kerning.
* After the code parses the OTF file, an integer overflow occurs and corrupts the memory.
* In this document we analyze the process which includes the ActionScript heap spray process finishing by triggering the vulnerability which permits code execution.
* Our lab environment is an English Windows XP SP3 operating system with Internet Explorer version 7 with Flash 11_3_300_268 installed.
13
INTEGER OVERFLOWS
* An integer overflow vulnerability differs a lot from other kinds of security issues such as buffer or heap overflows.
* One cannot hijack instantly the execution flow or directly write at arbitrary memory locations.
* 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.
* The Actionscript code was originally published over Internet. [15]
* If you are willing to know more about heap spraying, please read this this document https://www.htbridge.com/publication/CVE-2012-1889.pdf
15
THE ACTIONSCRIPT HEAPSPRAY CODE
16
THE CODE DETAILS
* The most important lines are 3, 4 and from 17 up to 29.
* At line 3 the class array is used to create an object named Memory.
* 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:
• Using EMET.
• Setting the protected view as the default mode.
• Enforcing ActiveX security settings.
36
REFERENCES
* [5] https://community.rapid7.com/community/metasploit/blog/2012/08/17/adobe-flash-player-exploit-cve-
* [15] http://code.google.com/p/roeehay/source/browse/trunk/Adobe_Flash_CVE-2009- 1869/src/HeapLib.as?r=2
THANK YOU FOR READING!
Your questions are always welcome! brian.mariani@htbridge.com frederic.bourla@htbridge.com
пиздец :D
ReplyDeleteVery good post! :P
ReplyDeleteinteger overflows are not that easy to decipher.. cool stuff dude!
ReplyDeletewhat is the password for samples??
ReplyDeleteI better understand integer overflow issues now, thanks for this post!
ReplyDeletebtw what is the password for the taiwan msg in your last post? Please could you share it?
Hi Mila
ReplyDeleteThis is great analysis thanks
interesting! although I have no expert, but I want have to know more and more, on your blog just interesting and useful information. Keep it up!hgh
ReplyDeleteIt's useful and detailed information, very apreciated!
ReplyDeleteClaudio
Very cool stuff...
ReplyDeleteI was wondering "from where" comes this fucking 0x1e0d0000 at my test crash!
ReplyDeletetoo complicated to me :\ but seems great stuff
ReplyDeletenice blog
ReplyDeleteexcellent information!
ReplyDelete