Expired Pointers of an Exported DLL Function

Once the dynamic-link library (DLL) is loaded in the memory, the address of an exported function is usually retrieved. The address is copied into a variable. Before the program executes the exported function, it retrieves its address from the variable. A potential vulnerability exists if the DLL is unloaded but the variable still contain the address of the exported function that was previously valid.

Here is one approach to get started the investigation into a potential vulnerability.

Let's assume the debugger executes the target application. We configure it to break-in when a DLL is unloaded. We know the base address and the size of the DLL as the debugger displays it. When the debugger breaks in we search for pointers that fall into this region. We set data access breakpoint for each pointer, and resume the execution to see if the pointers are accessed.

We may find that some of the pointers set to NULL when the breakpoint is triggered. This is most likely to prevent the access to invalid memory.

We may find that other expired pointers get copied into another memory location. This could be suspicious as we don't normally read expired pointers, albeit, often whole structures get copied even if they contain members that are no longer used.

We may find that some of the breakpoints are not triggered, and we need to analyze further if they can be reached from the execution flow.

Out of Memory Issues in Internet Explorer 9

Recently, I was examining how Internet Explorer 9 performs under low-memory conditions.

The test involves to consume large amount of memory in the virtual address space of the renderer process. In this circumstance the execution flow can proceed on error condition of the memory allocation call, and so we can test how the application behaves when the memory allocation fails.

I used the following Windbg script as a template to exhaust the memory of the renderer process. I run the tests with between 16M and few hundred megabytes of free memory in the virtual address space.

$$ Exhausts the memory in the virtual address space. The memory is considered
$$ to be exhausted when an allocation with 16M fails.
$$
$$ Example Usage: $$>< e:/exhaust.wds
$$
$$ Last Updated: 10/February/2013
r $t0 = 0x40000000;
.while (@$t0 >= 0x100000)
{
   r $t1 = 0;
   .echo
   .echo "Size     Address";
   .echo "-----------------";
   .while (@$t1 == 0) {
     r $t1 = 1;
     .catch {.foreach /pS 5 (Address {.dvalloc /r @$t0}) { .printf "%08x %08x\n", @$t0, Address;}; r $t1 = 0;}
   }
   r $t0 = @$t0 / 2;
}

I opened local HTML/SVG files that were legitimate rather than fuzzed, and visited random websites under low-memory conditions. During my experiment, I observed many access violations because of the failed memory allocations. Even though most of them are harmless ones (NULL pointer crashes) some ends up to read data from invalid memory addresses that are not NULL.

Out of memory problem could be a security risk, and this is an attack surface in Internet Explorer. A mitigation to handle this issue would be to implement the following wrapper around the function that allocates the memory. If the allocation fails the renderer process stops with int 3 exception, so we avoid enter to any potential vulnerable code path.

As a reference, here are some stack traces of NULL pointer crashes.

eax=16acc320 ebx=16acc320 ecx=7765e38c edx=00629d08 esi=00000000 edi=16acc324
eip=678b34c5 esp=04ac6854 ebp=04ac6858 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00210246
MSHTML!TSmartResource<CD2DDCTraits>::Acquire<ID2D1RenderTarget *,enum D2D1_DC_INITIALIZE_MODE,bool>+0x15:
678b34c5 8b06            mov     eax,dword ptr [esi]  ds:002b:00000000=????????
0:005> kb
ChildEBP RetAddr  Args to Child              
04ac6858 678b45bd 00000000 00000000 16dd9af0 MSHTML!TSmartResource<CD2DDCTraits>::Acquire<ID2D1RenderTarget *,enum D2D1_DC_INITIALIZE_MODE,bool>+0x15
04ac686c 678b4498 00000000 04ac689c 00000000 MSHTML!RefCounted<CD2DDCHolder,SingleThreadedRefCount>::Create<IDCHolder,ID2D1RenderTarget *>+0x5a
04ac68e8 678b3f9f 04acd308 04acd404 04ac69e0 MSHTML!CGDIRenderMode::OnBegin+0x37
04ac6914 678b416d 1125d810 04ac69e0 04acd404 MSHTML!CDXRenderTarget::GetDC+0x1e0
04ac6940 678b41ca 04ac6978 04ac69e0 16e55668 MSHTML!TSmartResource<CDispSurfaceDCMode>::Acquire<CDispSurface *,CRect const *>+0x6c
04ac6a68 67ac98b9 04acd268 04ac6c58 04ac6c18 MSHTML!COleLayout::Draw+0xd6f
04ac6a94 67ac9663 04ac6c58 04ac6c18 04acd308 MSHTML!CLayout::DrawClient+0xaa
04ac6d6c 67ac78e9 04acae4c 00000000 00000007 MSHTML!CDispLeafNode::DrawSelf+0x56c
04ac6e84 67ac82d0 169fe050 00000000 00000007 MSHTML!CDispNode::Draw+0x2c8
04ac6ea8 67ad9c5e 00000000 04ac6f74 04acae4c MSHTML!CDispContainer::DrawChildren+0xe4
04ac6f48 67ad9d15 1188efb8 04acae4c 04ac6f74 MSHTML!CDispContainer::DrawContentAdvanced+0x25c
04ac718c 67ac78e9 04acae4c 00000000 00000007 MSHTML!CDispContainer::DrawSelf+0x49b
04ac72a4 67adcb19 1188efb8 00000000 00000007 MSHTML!CDispNode::Draw+0x2c8
04ac72c8 67a82102 0ec815ec 1188efb8 04ac73c8 MSHTML!CDispNode::DrawContainerChild+0xd4
04ac7340 67a80e8b 0ec815a0 00000001 00000003 MSHTML!HtmlLayout::LineBoxBuilder::LsInlineBlockDisplay+0x71
04ac7358 67a801ca 1682e1f0 04ac73a0 0ec815a0 MSHTML!Ptls5::LsUpdateBreakRecordText+0xe4
04ac73d0 67adc0f8 112b8118 04ac7454 00000000 MSHTML!Ptls5::LsDisplayLine+0x19b
04ac747c 67adbf96 11576038 16a20920 1188ef60 MSHTML!HtmlLayout::LineBox::Draw+0x127
04ac75fc 67adbcb6 16a20920 04ac7698 00000000 MSHTML!HtmlLayout::FlowBox::DrawFlowItems+0x417
04ac76d0 67adba8d 04ac77b4 04ac77c4 04acd308 MSHTML!HtmlLayout::FlowBox::DrawClientContainerContent+0x1f7


eax=00000000 ebx=0767dc08 ecx=00000000 edx=67b36c31 esi=00000001 edi=0767dc08
eip=67b50f2c esp=043fd05c ebp=043fd070 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
MSHTML!CElement::AddRefCDocument:
67b50f2c 8b8130010000    mov     eax,dword ptr [ecx+130h] ds:002b:00000130=????????
0:005> kb
ChildEBP RetAddr  Args to Child              
043fd058 67b7ce5d 00000001 0767dc08 0972de00 MSHTML!CElement::AddRefCDocument
043fd070 67b7faa9 0767dc08 0e90b258 0e5f5d00 MSHTML!CElement::PrivateExitTree+0xfa
043fd0dc 67b7d897 0e90b258 00000001 00000001 MSHTML!CMarkup::DestroySplayTree+0x1fd
043fd150 67b87d82 00000000 00000001 0e5f5c20 MSHTML!CMarkup::UnloadContents+0x4bb
043fd170 67b94f28 0e90b258 00000001 00000000 MSHTML!CMarkup::TearDownMarkupHelper+0x4c
043fd198 67b96c2f 00000001 00000000 00000000 MSHTML!CMarkup::TearDownMarkup+0x71
043fd1c8 67b97190 0e5f5c20 00000000 0e5f5c20 MSHTML!CDoc::UnloadContents+0x5ee
043fd1e4 67b2adb8 0af3d9f8 0af3d9f8 043fd21c MSHTML!CDoc::Passivate+0x158
043fd1f4 67b59914 0e5f5c20 6783edfd 00000000 MSHTML!CBase::PrivateRelease+0x33
043fd1fc 6783edfd 00000000 0af3d9f8 00000000 MSHTML!TSmartPointer<IDispBrush>::Release+0x14
043fd20c 67b2adb8 008f8d10 00000000 043fd230 MSHTML!COleSite::Passivate+0x9f
043fd21c 67b2ac22 0af3d9f8 008f8d10 008ff680 MSHTML!CBase::PrivateRelease+0x33
043fd230 67b2acfe 0af3d9f8 043fd2b0 67bc5bdb MSHTML!CElement::PrivateRelease+0x40
043fd23c 67bc5bdb 0af3d9f8 008fecc8 67adfe91 MSHTML!CXDomainRequest::Release+0x10
043fd248 67adfe91 0e5ff8d0 008bc5a8 02000000 MSHTML!CMultimediaLog::Reset+0x28
043fd2b0 67ae017b 0e5ff8d0 00000000 00000001 MSHTML!COmWindowProxy::SwitchMarkup+0xadf
043fd338 679f4971 0e5ff8d0 00000000 0e5ff8d0 MSHTML!CMarkup::SetInteractiveInternal+0x183
043fd36c 67a04c0f 00000001 00000000 0e5ff8d0 MSHTML!CMarkup::RequestReadystateInteractive+0x152
043fd398 679eeaa7 008dd2c0 0aebcf70 0556e892 MSHTML!CMarkup::BlockScriptExecutionHelper+0x184
043fd4a4 679b7cf8 0556e892 008dd2c0 0aebcf70 MSHTML!CHtmPost::Exec+0x4b1


eax=00000000 ebx=00000000 ecx=07f4b8d4 edx=04b695fc esi=08564494 edi=00000000
eip=6789db2b esp=04b695ac ebp=04b695dc iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
MSHTML!CDXImageSoftware::CreateSharedBitmap+0xb4:
6789db2b 8b08            mov     ecx,dword ptr [eax]  ds:002b:00000000=????????
0:004> kb
ChildEBP RetAddr  Args to Child              
04b695dc 6789d969 00000000 081efac4 04b695fc MSHTML!CDXImageSoftware::CreateSharedBitmap+0xb4
04b69610 67ace39f 745b8fc0 081efac4 00000000 MSHTML!CDXImageSoftware::PrepareToRenderImpl+0x82
04b69644 67e7c992 08564480 745b8fc0 00000000 MSHTML!CDXImage::PrepareToRender+0x7c
04b696e0 67c0c4cf 745b8fc0 04b69878 04b6973c MSHTML!CSATBlurRenderer::CreateBlurredTarget+0x33b
04b69774 677faef8 745b8fc0 04b69954 40000000 MSHTML!CDXRenderTarget::Gaussian+0x1bf
04b699b8 677fa4d6 04b69a9c 04b69bd0 00000000 MSHTML!CDispSurface::RenderShadows+0xcc0
04b69cac 67adb82f 6a5a4220 04b69d28 081fbca0 MSHTML!HtmlLayout::ContainerBox::PositionAndDrawBackground+0x1170
04b69d58 67adb6b2 081f1d18 04b6d8d8 081fbca0 MSHTML!HtmlLayout::ContainerBox::DrawBackgrounds+0x210
04b69d88 67aca06f 04b69f6c 04b69e7c 04b6d978 MSHTML!HtmlLayout::ContainerBox::DrawClientBackground+0x6f
04b69e94 67ac9f07 04b6b4bc 00000000 04b6b4bc MSHTML!CDispNode::DrawBackground+0x1c0
04b6a0cc 67ac78e9 04b6b4bc 00000000 00000007 MSHTML!CDispContainer::DrawSelf+0x2b0
04b6a1e4 67ac82d0 081fbca0 00000000 00000007 MSHTML!CDispNode::Draw+0x2c8
04b6a208 67ad9c5e 00000000 04b6a2d4 04b6b4bc MSHTML!CDispContainer::DrawChildren+0xe4
04b6a2a8 67ad9d15 07c69e18 04b6b4bc 04b6a2d4 MSHTML!CDispContainer::DrawContentAdvanced+0x25c
04b6a4ec 67ac78e9 04b6b4bc 00000000 00000007 MSHTML!CDispContainer::DrawSelf+0x49b
04b6a604 678d0958 07c69e18 00000000 00000007 MSHTML!CDispNode::Draw+0x2c8
04b6a64c 67ac78e9 04b6b4bc 00000000 00000007 MSHTML!CDispProxyNode::DrawSelf+0x11d
04b6a764 67ac82d0 0849b398 00000000 00000007 MSHTML!CDispNode::Draw+0x2c8
04b6a788 678d0896 04b6d978 04b6a854 04b6b4bc MSHTML!CDispContainer::DrawChildren+0xe4
04b6a828 67ad9d15 745b8da8 04b6b4bc 04b6a854 MSHTML!CDispContainer::DrawContentAdvanced+0x28d


eax=0684a9a0 ebx=00000000 ecx=727937c0 edx=0000025b esi=73de91e8 edi=00000001
eip=6682bbbb esp=0440d190 ebp=0440d1a0 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
jscript9!Js::JavascriptOperators::OP_GetInstanceScoped+0x2a:
6682bbbb 8b4304          mov     eax,dword ptr [ebx+4] ds:002b:00000004=????????
0:005> kb
ChildEBP RetAddr  Args to Child              
0440d1a0 09ed0071 00000003 0000025b 5ce84740 jscript9!Js::JavascriptOperators::OP_GetInstanceScoped+0x2a
WARNING: Frame IP not in any known module. Following frames may be wrong.
0440d1c8 668085fe 725d5980 00000002 02f5bcf0 0x9ed0071
0440d204 66808523 725d5980 6680cb68 00000002 jscript9!Js::JavascriptFunction::CallFunction+0xc4
0440d268 6680845a 0a244dc8 00000002 0440d360 jscript9!Js::JavascriptFunction::CallRootFunction+0xb6
0440d2a4 668083e6 00000000 0440d2d4 00000002 jscript9!ScriptSite::CallRootFunction+0x4f
0440d2cc 6687e0d7 725d5980 0440d2fc 00000000 jscript9!ScriptSite::Execute+0x63
0440d330 67a824a9 0a23606c 725d5980 00000002 jscript9!ScriptEngine::Execute+0x11a
0440d3b4 67a823d3 725d5980 094bfae8 63beed58 MSHTML!CListenerDispatch::InvokeVar+0x12a
0440d3d4 678ead1f 094bfae8 0440d438 0440d498 MSHTML!CListenerDispatch::Invoke+0x40
0440d5a4 67b6bbfc 094bfae8 728f5120 00000000 MSHTML!CEventMgr::Dispatch+0x537
0440d5cc 68073e2c 728f5120 7ec86aa0 ffffffff MSHTML!CEventMgr::DispatchEvent+0xc9
0440d5e0 68079c98 6a40df58 adc49da3 00000096 MSHTML!CSVGElement::Fire_SVGLoad+0x37
0440d5f8 680760bd 0440d620 67b77389 728f5120 MSHTML!CSVGSVGElement::Fire_SVGLoad+0x53
0440d600 67b77389 728f5120 00000000 00008003 MSHTML!CSVGElement::Fire_SVGLoad_Async_Handler+0x10
0440d620 67b77406 748dbf58 00000001 90fa7997 MSHTML!CAsyncEventQueue::DispatchAllEvents+0x7c
0440d670 74fb62fa 00700e80 00000aae 748dbf58 MSHTML!GlobalWndProc+0x2ed
0440d69c 74fb6d3a 67b145ee 00700e80 00008003 USER32!InternalCallWinProc+0x23
0440d714 74fb77c4 00000000 67b145ee 00700e80 USER32!UserCallWinProcCheckWow+0x109
0440d774 74fb788a 67b145ee 00000000 0440f8a8 USER32!DispatchMessageWorker+0x3bc
0440d784 6b8a205c 0440d7cc 001f6db0 001f6dcc USER32!DispatchMessageW+0xf


eax=04666084 ebx=0bd43ae8 ecx=04666060 edx=0466067f esi=00000000 edi=0bd43b48
eip=6908145b esp=04666078 ebp=046661ec iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
MSHTML!CSVGEmbeddedComponent::CreateDisplayTreeForEmbeddedContent+0x79:
6908145b 8b06            mov     eax,dword ptr [esi]  ds:002b:00000000=????????
0:005> kb
ChildEBP RetAddr  Args to Child              
046661ec 69081acc 0bd43ae8 0bd43ae8 0bd43aec MSHTML!CSVGEmbeddedComponent::CreateDisplayTreeForEmbeddedContent+0x79
04666208 68e5dda5 01d43ae8 0c2c0068 00000001 MSHTML!CSVGEmbeddedComponent::EnsureLayoutForEmbeddedComponent+0xf7
04666260 690b59c3 0b010600 04669bd8 046662b4 MSHTML!CImgHelper::DrawSVGImage+0x29f
046662d8 68ffe222 04669bd8 0466630c 12d406e8 MSHTML!CSVGImageBlock::Draw+0x1a8
0466631c 68ad6f4e 04666354 6901ae94 046663dc MSHTML!HtmlLayout::SvgPrimitiveBox::DrawClient+0x117
04666380 770f26a4 00000000 04669bd8 046677bc MSHTML!CDispDrawContext::GetRedrawRegionBounds+0x7b
04666498 770f256f 0edcc0a8 00000090 04669ce4 ntdll!RtlpReAllocateHeap+0x190
0466650c 68ad6f4e 00570000 00000000 0edcc0a8 ntdll!RtlReAllocateHeap+0x2c5
04666548 68ad8db1 046677bc 04669ce4 00000000 MSHTML!CDispDrawContext::GetRedrawRegionBounds+0x7b
046677bc 00000000 00000000 00000000 04667804 MSHTML!CDispSurface::CClipStack::PushClipRect+0x181


eax=00000024 ebx=00005867 ecx=00000009 edx=00000016 esi=0435d008 edi=00000000
eip=68ffaa2c esp=0435cf98 ebp=0435d18c iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
MSHTML!HtmlLayout::SvgTextBoxBuilder::CalculateGlyphWidths+0xaf:
68ffaa2c f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
0:005> kb
ChildEBP RetAddr  Args to Child              
0435d18c 68ffa7cc 08fab420 0435d1d0 61b9c288 MSHTML!HtmlLayout::SvgTextBoxBuilder::CalculateGlyphWidths+0xaf
0435d1d8 68ff8684 00fab420 6adadd40 0435d478 MSHTML!HtmlLayout::SvgTextBoxBuilder::UpdateVisibleRectangle+0x7f
0435d280 68ff8150 08fab420 0435d478 08fab420 MSHTML!HtmlLayout::SvgTextBoxBuilder::BuildLine+0x4d2
0435d2a8 68a36a8d 0d01ff24 0435d478 0d01ff18 MSHTML!HtmlLayout::SvgTextBoxBuilder::MoveToNextPosition+0xb5
0435d2d4 68a33951 08fab420 0435d478 0d01ff18 MSHTML!HtmlLayout::LayoutBuilder::EnterBlock+0xca
0435d2f0 68a359e4 0435d420 0435d464 00000000 MSHTML!HtmlLayout::LayoutBuilder::Move+0x48
0435d3c0 68a319af 0ad93c90 00000000 0ad93c90 MSHTML!HtmlLayout::LayoutBuilderDriver::StartPartialLayout+0x2d1
0435d4a0 68a2ffcc 0c10ddb8 00000000 00000032 MSHTML!HtmlLayout::CIE9Page::LayoutPage+0x27c
0435d4cc 68a2c3a7 00000000 0c10ddb8 08fa0c90 MSHTML!HtmlLayout::CIE9DocumentLayout::FormatPage+0x65
0435d524 68a272fe 0c8dff24 00000000 08fa0c90 MSHTML!CCssDocumentLayout::FindOrFormatPage+0x272
0435d590 68a2deff 0ad93c90 0c8dff24 00000032 MSHTML!CCssDocumentLayout::GetPage+0x95b
0435d638 68a2dd12 0c8dff20 0435d654 0435d6c8 MSHTML!CMarkupPageLayout::CalcSize+0x28c
0435d6b0 68a2fa31 00100000 0435d6c8 0c8dff34 MSHTML!CMarkupPageLayout::CalcTopLayoutSize+0x101
0435d6d4 68c9b1d1 00100000 00002000 00000000 MSHTML!CMarkupPageLayout::DoLayout+0x56
0435d710 68a16b35 0c602e1c 00100000 00000000 MSHTML!CView::ExecuteLayoutTasks+0x3b
0435d77c 68a3856b 00000000 004d4f80 004d4fb4 MSHTML!CView::EnsureView+0x3bf
0435d7a4 68b49ef9 0c602e1c 00000000 00000000 MSHTML!CView::EnsureViewCallback+0xb8
0435d7e0 68b69768 3286b286 00000000 68b245ee MSHTML!GlobalWndOnMethodCall+0x115
0435d828 764e62fa 000909b6 0000005b 00000000 MSHTML!GlobalWndProc+0x302
0435d854 764e6d3a 68b245ee 000909b6 00008002 USER32!InternalCallWinProc+0x23


eax=00000001 ebx=00000000 ecx=00000000 edx=765d4758 esi=00000000 edi=00000000
eip=7675561c esp=043dcb38 ebp=043dcb40 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
SHLWAPI!StrCmpNICW+0x13:
7675561c 0fb706          movzx   eax,word ptr [esi]       ds:002b:00000000=????
0:005> kb
ChildEBP RetAddr  Args to Child              
043dcb40 765d5704 00000000 765d4758 00000004 SHLWAPI!StrCmpNICW+0x13
043dcb60 765fcf6f 043dd000 72865284 00000000 urlmon!IsKnownProtocol+0x1e
043dcba4 68903047 007e81e8 00000000 00000000 urlmon!COInetSession::CreateBinding+0xf2
043dcbd8 68902f8f 72865284 00000000 00000000 MSHTML!CTridentFilterHost::CreateInetProtBinding+0x45
043dcc04 689c6406 00000000 00000000 043dd000 MSHTML!CTridentFilterHost::BindToInetProt+0x112
043dce98 689c18ba 72865218 00000000 00000004 MSHTML!CDwnBindData::Bind+0x4ba
043dcec0 689c16f6 00000000 68756ef4 00000000 MSHTML!NewDwnBindData+0x19d
043dcf1c 68a0a3bd 68756ee0 043dd000 6db14b88 MSHTML!CDwnLoad::Init+0x25c
043dcf40 68b62217 043dd000 6db14b88 00000001 MSHTML!CImgLoad::Init+0x43
043dcf68 68b6211d 07083df0 00000000 043dd000 MSHTML!CDwnInfo::SetLoad+0x11e
043dcf88 68b6c334 00000001 043dd000 00000000 MSHTML!CDwnCtx::SetLoad+0x86
043dcfb4 689f1547 00000001 043dd000 00000000 MSHTML!CImgCtx::SetLoad+0x4d
043dd058 689cc92d 00000001 0a4a138c 08df93b0 MSHTML!CDoc::NewDwnCtx2+0x337
043dd088 68ab962d 6fcd52a0 00000001 08df93b0 MSHTML!CDoc::NewDwnCtx+0x5b
043dd0d4 68aba4c3 07083df0 679f53e8 00000004 MSHTML!CImgHelper::FetchAndSetImgCtx+0xfb
043dd0f8 68aba3df 043dd1b8 08df93b0 043dd184 MSHTML!CImgHelper::EnterTree+0x132
043dd16c 6908fd6c 06f03f20 043dd1b8 043dd1b8 MSHTML!CImgHelper::Notify+0x2a4
043dd18c 689c2fa1 043dd1b8 00000001 6f48ea00 MSHTML!CSVGImageElement::Notify+0x2c
043dd1ec 689c2e5f 6f48ea00 6db102d8 689c7aa7 MSHTML!CHtmRootParseCtx::FlushNotifications+0x1b6
043dd1f8 689c7aa7 00000000 74702280 74702280 MSHTML!CHtmRootParseCtx::Commit+0xb

Entering into Out of Memory Condition

In this blog post I'm describing an approach to force the execution flow to enter into out of memory (OOM) error conditions when the amount of memory to allocate is not controlled by the attacker as in the example below.

#define MAX_SIZE 0x08000000 /* 128M */

ptr = malloc(MAX_SIZE)
if (ptr == NULL)
{
  return OUT_OF_MEMORY;
}

When testing software, it's reasonable to think that error conditions like above are unlikely to be reached as often as other error conditions. Some of them may never get reached because it's not obvious to make the allocation with fixed-size to fail.

OOM error condition could be a potential to enter into vulnerable code path. One example I've heard that the memory allocation had failed and the error condition led to call the cleanup functionality which caused to free of uninitialized pointer.

When testing, one possible way to make memory allocation to fail is to hook the memory allocation function and change the functionality to fail, that is to return with NULL pointer. However, I wanted to avoid this approach of testing because even if I find bug I'd still need a lot of work to reproduce it in real word scenario (if possible at all), when the hook is not applied.

Therefore, what I thought is that the other way to force fixed-size memory allocation to fail is to consume large amount of memory of the virtual address space, and as a consequence the program will be operating under low-memory conditions. This means if memory allocation occurs with reasonable small size it could fail because there is not much memory available. My theory is that any vulnerability found that we reach via OOM error conditions can be reproduced in a real word scenario because we always expect to find something that triggers to consume large amount memory in order to make other allocation to fail. This is pretty much possible in browsers where basically you can easily fill arbitrary amount of the heap memory.

Experimentally, I involved this approach in my fuzzing methodology. I attach the target process to Windbg and execute .dvalloc command to allocate arbitrary amount of memory in the virtual address space. The amount of memory available in the address space can be queried with !address -summary command, or can be seen in Process Explorer, and so you can allocate more for your test if needed.

When testing Firefox with this methodology I notice increased amount of int 3 crashes in mozalloc_abort() that is due to out of memory condition - those crashes are not exploitable though.

An Attempt to Make a Read Access Violation Exploitable

This is the analysis of an attempt to make a read access violation exploitable. The bug is found in the 64-bit version of Internet Explorer 9 (9.0.8112.16421).

The crash happens when trying to open the SVG file with the below content. Note, that CDATA (stands for charachter data) doesn't have any element content leading to crash.

<?xml version="1.0" encoding="utf-8"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
    <![CDATA[]]>
</svg>

These are the registers and the faulting instruction when the read access violation occurs.

0:005> r
rax=0000000000000000 rbx=00000000042bc2b0 rcx=00000000ffffffff
rdx=0000000000000000 rsi=0000000000000002 rdi=00000000042bbdc0
rip=000000005bd9aff5 rsp=00000000042bc4d0 rbp=00000000002844b0
 r8=0000000000000000  r9=0000000000000084 r10=000000005c7c1b00
r11=000000000eb1d7a0 r12=00000000042bc570 r13=0000000000000000
r14=00000000002844b0 r15=0000000000000001
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010244
MSHTML!CHtmSpaceParseCtx::AddNonspaces+0x134:
00000000`5bd9aff5 410fb70c4c      movzx   ecx,word ptr [r12+rcx*2] ds:00000002`042bc56e=????

This is the call stack. It's not used to support any of claims but it's pasted for information only.

0:005> k
Child-SP          RetAddr           Call Site
00000000`042bc4d0 00000000`5bc7c249 MSHTML!CHtmSpaceParseCtx::AddNonspaces+0x134
00000000`042bc530 00000000`5bc7c153 MSHTML!CHtmCrlfParseCtx::AddTextIE9+0x146
00000000`042bc7c0 00000000`5bd2bd17 MSHTML!CHtmCrlfParseCtx::AddText+0x24
00000000`042bc800 00000000`5bd7daa5 MSHTML!CHtmParse::ParseText+0x349
00000000`042bc9c0 00000000`5bd2d36e MSHTML!CHtmParse::ParseToken+0x2d2
00000000`042bca00 00000000`5bd20980 MSHTML!CHtmPost::ProcessTokens+0x49b
00000000`042bcd00 00000000`5bd20f7b MSHTML!CHtmPost::Exec+0x274
00000000`042bcf10 00000000`5bd20e81 MSHTML!CHtmPost::Run+0x5a
00000000`042bcf50 00000000`5bd206eb MSHTML!PostManExecute+0x1ae
00000000`042bcfa0 00000000`5bd1f4e0 MSHTML!CDwnChan::OnMethodCall+0x1b
00000000`042bcfd0 00000000`5bdeb468 MSHTML!GlobalWndOnMethodCall+0x18b
00000000`042bd060 00000000`771d9bd1 MSHTML!GlobalWndProc+0x36c
00000000`042bd0e0 00000000`771d98da USER32!UserCallWinProcCheckWow+0x1ad
00000000`042bd1a0 000007fe`ebfdaf5e USER32!DispatchMessageWorker+0x3b5
00000000`042bd220 000007fe`ebf87754 IEFRAME!CTabWindow::_TabWindowThreadProc+0x9c1
00000000`042bf680 00000000`76d153b3 IEFRAME!LCIETab_ThreadProc+0x39f
00000000`042bf820 000007fe`ebf68dcb iertutil!CIsoScope::RegisterThread+0x10f
00000000`042bf850 00000000`76bf652d IEFRAME!Detour_DefWindowProcA+0x97
00000000`042bf890 00000000`772ec521 kernel32!BaseThreadInitThunk+0xd
00000000`042bf8c0 00000000`00000000 ntdll!RtlUserThreadStart+0x1d

After restarting Internet Explorer and the debugger (leading different memory layout), I set a breakpoint at the address of the faulting instruction.

0:005> g
Breakpoint 0 hit
MSHTML!CHtmSpaceParseCtx::AddNonspaces+0x134:
00000000`69f0aff5 410fb70c4c      movzx   ecx,word ptr [r12+rcx*2] ds:00000002`0421cb2e=????

r12 is the base address of a structure. The instruction reads a word value from the structure using a delta value that is RCX*2. In our case, RCX is 0`ffffffff which cannot be a valid delta value as the size of the memory region of the structure is only 4000 bytes as seen below. Therefore by executing the instruction it reads out of the bounds of the structure, that is likely an invalid memory address.

0:005> !vprot r12
BaseAddress:       000000000421c000
AllocationBase:    0000000004020000
AllocationProtect: 00000004  PAGE_READWRITE
RegionSize:        0000000000004000
State:             00001000  MEM_COMMIT
Protect:           00000004  PAGE_READWRITE
Type:              00020000  MEM_PRIVATE

By allocating memory at the address of the invalid read we can execute the instruction without causing exception.

MSHTML!CHtmSpaceParseCtx::AddNonspaces+0x134:
00000000`69f0aff5 410fb70c4c      movzx   ecx,word ptr [r12+rcx*2] ds:00000002`0421cb2e=????
0:005> .dvalloc /b 2`0421c000 1000
Allocated d000 bytes starting at 00000002`04210000

As seen below, movzx now tries to access to a valid memory region recently allocated by .dvalloc, filled with zeroes. If we let the program execute now it doesn't crash. Even if we refresh the SVG file it doesn't cause a read access violation because now the memory movzx tries to access is a valid address in the virtual address space.

0:005> r
rax=0000000000000000 rbx=0000000000000000 rcx=00000000ffffffff
rdx=0000000000000000 rsi=0000000000000000 rdi=000000000033bd50
rip=0000000069f0aff5 rsp=000000000421ca90 rbp=000000000df58d90
 r8=0000000000000000  r9=000000000e03fee0 r10=000000000dfe4401
r11=0000000000000001 r12=000000000421cb30 r13=0000000000000000
r14=000000000df58d90 r15=0000000000000001
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
MSHTML!CHtmSpaceParseCtx::AddNonspaces+0x134:
00000000`69f0aff5 410fb70c4c      movzx   ecx,word ptr [r12+rcx*2] ds:00000002`0421cb2e=0000

When the instruction is executed it reads the tainted word value to ECX. As seen below, the word value is copied to a second structure. At this point the tainted data is copied to a second structure.

0:005> p
MSHTML!CHtmSpaceParseCtx::AddNonspaces+0x13c:
00000000`69f0affd 66894f7c        mov     word ptr [rdi+7Ch],cx ds:00000000`0033bdcc=0020

Using the PoC, later on the execution the program doesn't read the tainted data from the second structure that is verified by processor breakpoint.

The tainted word value was zero as .dvalloc filled the memory with zeroes. Since we know the address of the word value we can try all the 65536 possibilities and watch what happens when processing the different word values. To achieve this I wrote a wrapper HTML which calls the SVG file periodically. Also, I set up the below commands which does the job automatically, so in every iteration we provide different tainted input in range of 0 to 65535.

0:005> bc 0
0:005> r $t0 = 0;
0:005> bp 69f0aff5 "j @ecx=ffffffff 'ew 2`0421cb2e @$t0; r $t0 = @$t0 + 1; .if (@$t0 <= 0xffff) { gc }'; gc"
0:005> g

When the command completed I concluded that we tried all the word values but neither of them seem to trigger unusual code paths using the PoC.

Further analyzing the data flow there is a possible place when the tainted data could be used to make decision on the execution flow, and it's the following.

MSHTML!CHtmSpaceParseCtx::AddNonspaces+0x87:
00000000`69f4823e 0fb74f7c        movzx   ecx,word ptr [rdi+7Ch]
00000000`69f48242 6685c9          test    cx,cx
00000000`69f48245 0f8511b8d2ff    jne     MSHTML!CHtmSpaceParseCtx::AddNonspaces+0x90 (00000000`69c73a5c)

If this code can be reached when [rdi+7c] is the tainted data that might have consequence due to the complexity of the code paths in this function. I however was unable to reach this code path in my experience.

The address of invalid read is predictable by the attacker as it's always 2 x 0`ffffffff plus something which can be filled with attacker controlled data. But this doesn't seem to be relevant as Microsoft just confirmed that they had finished their investigation into this crash and as they say "[we] can confirm that this crash is caused by a read AV which is not exploitable." I believe them and I no longer investigate this but will focus on other crashes, but thought to share this.

An Example for Hidden NULL Pointer Bug

When performing security testing of the native application I often attach Windbg to the target process. The obvious benefit of this methodology is that when an exception occurs it's possible to immediately analyze and save the state information of the program. There is one more important benefit, and that is you can get additional information of the running application if you set certain options beforehand. For example, sxn ud command sets up the debugger to send notification when a module is unloaded. I find very useful to analyze Windbg log during security testing, rather than just relying to find exception or memory corruption.

Some time ago, during testing Internet Explorer 9, I noticed that Windbg screen had been flooded with the following messages.

Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.

The application continued running without displaying more of these messages and there was no sign the integrity of the application corrupted. My first thought was it's the result of one of Windbg commands I set up earlier just before executing the test. The second thought was that it is unlikely because it seems to be a CRT error message, that most likely comes from the runtime DLL. I knew there is a way to send message to the debugger from an executable and that is to call OutputDebugString function.

I set up a breakpoint for OutputDebugString, and rerun the test. Here is the call stack when the breakpoint hit.

0:005> k
Child-SP          RetAddr           Call Site
00000000`04448388 000007fe`fdfd2478 KERNELBASE!OutputDebugStringA
00000000`04448390 000007fe`fdfd249b msvcrt!invoke_watson+0x98
00000000`044488d0 000007fe`fdfb0439 msvcrt!invalid_parameter+0x13
00000000`04448910 00000000`6027290f msvcrt!wcsnicmp+0x40
00000000`04448950 00000000`6000b522 MSHTML!CMultimediaLog::ExtractVideoData+0x8f
00000000`04448a30 00000000`600077ba MSHTML!CDoc::ExecHelper+0x4308
00000000`044498b0 000007fe`f1a22805 MSHTML!CDoc::Exec+0x2a
00000000`04449900 000007fe`f1a222f1 IEFRAME!CDocObjectHost::_PopulateOnlineHistoryData+0x141
00000000`04449990 000007fe`f1a21ecb IEFRAME!CDocObjectHost::_UpdateHistoryAndIntSiteDB+0x229
00000000`0444cb10 000007fe`f1a22001 IEFRAME!CDocObjectHost::_OnReadyState+0x21b
00000000`0444cda0 000007fe`f1a220bc IEFRAME!CDocObjectHost::_OnChangedReadyState+0xd1
00000000`0444ce70 00000000`5ff33c27 IEFRAME!CDocObjectHost::OnChanged+0x1c
00000000`0444cea0 00000000`5ff31380 MSHTML!CBase::FirePropertyNotify+0x3a3
00000000`0444cf30 00000000`5ff7f874 MSHTML!CMarkup::SetReadyState+0x41a
00000000`0444cfb0 00000000`5ff323b1 MSHTML!CMarkup::OnLoadStatusDone+0x3eb
00000000`0444d070 00000000`5ff7ef3f MSHTML!CMarkup::OnLoadStatus+0xb2
00000000`0444d0a0 00000000`5ff2f4e0 MSHTML!CProgSink::DoUpdate+0x5f5
00000000`0444d530 00000000`5fffb468 MSHTML!GlobalWndOnMethodCall+0x18b
00000000`0444d5c0 00000000`76de9bd1 MSHTML!GlobalWndProc+0x36c
00000000`0444d640 00000000`76de98da USER32!UserCallWinProcCheckWow+0x1ad
00000000`0444d700 000007fe`f198af5e USER32!DispatchMessageWorker+0x3b5
00000000`0444d780 000007fe`f1937754 IEFRAME!CTabWindow::_TabWindowThreadProc+0x9c1
00000000`0444fbe0 00000000`771553b3 IEFRAME!LCIETab_ThreadProc+0x39f
00000000`0444fd80 000007fe`f1918dcb iertutil!CIsoScope::RegisterThread+0x10f
00000000`0444fdb0 00000000`76ee652d IEFRAME!Detour_DefWindowProcA+0x97
00000000`0444fdf0 00000000`774dc521 kernel32!BaseThreadInitThunk+0xd
00000000`0444fe20 00000000`00000000 ntdll!RtlUserThreadStart+0x1d

Looking at the parameter of OutputDebugString I saw the followings.

0:005> db @rcx
000007fe`fe014110  49 6e 76 61 6c 69 64 20-70 61 72 61 6d 65 74 65  Invalid paramete
000007fe`fe014120  72 20 70 61 73 73 65 64-20 74 6f 20 43 20 72 75  r passed to C ru
000007fe`fe014130  6e 74 69 6d 65 20 66 75-6e 63 74 69 6f 6e 2e 0a  ntime function..
000007fe`fe014140  00 00 00 00 3a 20 00 00-0a 00 0a 00 00 00 00 00  ....: ..........
000007fe`fe014150  2e 00 2e 00 2e 00 00 00-00 00 00 00 00 00 00 00  ................
000007fe`fe014160  4d 00 69 00 63 00 72 00-6f 00 73 00 6f 00 66 00  M.i.c.r.o.s.o.f.
000007fe`fe014170  74 00 20 00 56 00 69 00-73 00 75 00 61 00 6c 00  t. .V.i.s.u.a.l.
000007fe`fe014180  20 00 43 00 2b 00 2b 00-20 00 52 00 75 00 6e 00   .C.+.+. .R.u.n.

This confirms this function sends the message to the debugger. We also see that OutputDebugString is called from wcsnicmp that is called from CMultimediaLog::ExtractVideoData.

I set up a breakpoint just before we call wcsnicmp.

0:005> ub MSHTML!CMultimediaLog::ExtractVideoData+0x8f
MSHTML!CMultimediaLog::ExtractVideoData+0x69:
00000000`602728e9 7409            je      MSHTML!CMultimediaLog::ExtractVideoData+0x74 (00000000`602728f4)
00000000`602728eb 488b01          mov     rax,qword ptr [rcx]
00000000`602728ee ff9020050000    call    qword ptr [rax+520h]
00000000`602728f4 4c8b6c2428      mov     r13,qword ptr [rsp+28h]
00000000`602728f9 488d15480f6900  lea     rdx,[MSHTML!`string' (00000000`60903848)]
00000000`60272900 41b807000000    mov     r8d,7
00000000`60272906 498bcd          mov     rcx,r13
00000000`60272909 ff1591ca5e00    call    qword ptr [MSHTML!_imp__wcsnicmp (00000000`6085f3a0)]

The place of the breakpoint is the highlighted line above.

Here we are when the breakpoint is hit.

Breakpoint 2 hit
MSHTML!CMultimediaLog::ExtractVideoData+0x89:
00000000`60272909 ff1591ca5e00    call    qword ptr [MSHTML!_imp__wcsnicmp (00000000`6085f3a0)] ds:00000000`6085f3a0={msvcrt!wcsnicmp (000007fe`fdf93330)}

Note that wcsnicmp takes three parameters: string1, string2, and count. These describes null-terminated strings and number of characters to compare.

I checked the parameters of wcsnicmp and saw the followings.

0:005> r rcx;r rdx;r r8
rcx=0000000000000000
rdx=0000000060903848
r8=0000000000000007

string2 and count both look healthy however string1 is NULL but the API documentation expects a string.

To make sure everything is ok with string2 let's check.

0:005> du @rdx
00000000`60903848  "http://"

It's fine, so the only problem with parameter string1 and the problem is that a NULL pointer is passed rather than a pointer to the string.

Microsoft long time ago added security enhancements in the CRT library. One of them involves to call invalid parameter handler which, for example, checks for NULL pointer parameters, and we terminate gracefully rather than with invalid memory access exception.

As you can see the return value is the highest positive value that can be represented in signed 32-bit. If the application is not prepared to handle this edge value it could cause problem later on the execution. Fortunately, that was not the case with Internet Explorer.

0:005> g 6027290f
MSHTML!CMultimediaLog::ExtractVideoData+0x8f:
00000000`6027290f baffff0000      mov     edx,0FFFFh
0:005> r eax
eax=7fffffff

The NULL check suppresses the crash but the application likely having problems managing the lifetime of objects.

Developers are advised to avoid the use of wcsnicmp() function as it's deprecated. Please check references what to use instead.

References

Security Features in the CRT

strnicmp, wcsnicmp

Flash Player Enables Sandbox via Global Pointer

The Windows version of Adobe Flash Player in Firefox has protected mode functionality. The concept of this mode is similar to the sandbox concept in Chrome: there is a broker process and a renderer process. The renderer process is running in low-integrity mode, and communicating with the broker process. The broker process is to give permission for legitimate system change but to reject questionable request made by the renderer process. The basic idea is the flash file is loaded and executed by the renderer process so, any non-legitimate invocation occurs by a vulnerability it will be rejected by the broker process.

Possible ways to circumvent the protection provided by protected mode include the followings. Corrupt the borkerer process to accept non-legitimate request from the renderer process. Or find Windows vulnerability to escalate right in low-integrity (i.e. renderer) process. Since the previous implementation when we didn't have the protected mode functionality is still available in the Flash Player it sounds to be logical by the attacker to disable protected mode functionality so the flash file is loaded and executed without sandbox protection. I'm exploring the latter further.

I examined NPSWF32_11_4_402_278.dll (11,264,432 bytes) file that is used in Firefox. In my test environment the DLL was located in C:\Windows\SysWOW64\Macromed\Flash folder. This file has the logic to decide if the flash file should be loaded and executed with or without sandbox protection. Flash Player uses a global pointer variable at fixed address (RVA: 0a2be70h) to store if sandbox mode should be used (1/0: with/without sandbox).

The value via the global pointer set to 1 by default (sandbox enabled) but it can be overwritten by adding ProtectedMode = 0 line to mms.cfg file that is located in the folder mentioned above.

Both the value and the page of the global pointer have the memory protection flags of read and write and since the global pointer is at a fixed address it's possible to overwrite it without changing memory protection flags or guessing the address.

Even though there is a need for a vulnerability to overwrite the global pointer table from security point of view it would be logical to discard the fixed address method and the writable memory protection flag. Using random address with read only page (apply writable flag when it's needed) would be more appropriate.

Here come some research artifacts.

Hijacking global pointer in Windbg. Higlighted dword is our new protected mode flag that is disabled.

0:000> sxe ld:NPSWF32_11_4_402_278
0:000> g
ModLoad: 59fe0000 5abbb000   C:\Windows\SysWOW64\Macromed\Flash\NPSWF32_11_4_402_278.dll
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=fffdd000 edi=0059bfcc
eip=7784fc42 esp=0059bea0 ebp=0059bef4 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
ntdll!NtMapViewOfSection+0x12:
7784fc42 83c404          add     esp,4
0:000> db 59fe0000 +a2be70
5aa0be70  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
5aa0be80  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
5aa0be90  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
5aa0bea0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
5aa0beb0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
5aa0bec0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
5aa0bed0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
5aa0bee0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
0:000> .dvalloc 1000
Allocated 1000 bytes starting at 00730000
0:000> db 00730000
00730000  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00730010  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00730020  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00730030  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00730040  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00730050  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00730060  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00730070  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
0:000> ed 59fe0000 +a2be70 00730000
0:000> g

Setting up protected mode flag below.

56245e56 807dff00        cmp     byte ptr [ebp-1],0
56245e5a 7406            je      NPSWF32_11_4_402_278!NP_SetNPAPIHostProxy+0x168c (56245e62)
56245e5c 8b45f8          mov     eax,dword ptr [ebp-8]
56245e5f c60001          mov     byte ptr [eax],1
56245e62 8bcb            mov     ecx,ebx

Checking if protected mode flag is set below.

56245e6f 8b75f8          mov     esi,dword ptr [ebp-8]
56245e72 59              pop     ecx
56245e73 803e00          cmp     byte ptr [esi],0
56245e76 0f8411010000    je      NPSWF32_11_4_402_278!NP_SetNPAPIHostProxy+0x17b7 (56245f8d) [br=1]

Highlighted code path of initialization with protected mode disabled below.

562460b0 e8dffeffff      call    NPSWF32_11_4_402_278!NP_SetNPAPIHostProxy+0x17be (56245f94)
562460b5 84c0            test    al,al
562460b7 7414            je      NPSWF32_11_4_402_278!NP_Initialize+0x57 (562460cd) [br=1]
562460b9 56              push    esi
562460ba e83bf4ffff      call    NPSWF32_11_4_402_278!NP_SetNPAPIHostProxy+0xd24 (562454fa)
562460bf 59              pop     ecx
562460c0 84c0            test    al,al
562460c2 7404            je      NPSWF32_11_4_402_278!NP_Initialize+0x52 (562460c8)
562460c4 33c0            xor     eax,eax
562460c6 eb0a            jmp     NPSWF32_11_4_402_278!NP_Initialize+0x5c (562460d2)
562460c8 33c0            xor     eax,eax
562460ca 40              inc     eax
562460cb eb05            jmp     NPSWF32_11_4_402_278!NP_Initialize+0x5c (562460d2)
562460cd e83595ffff      call    NPSWF32_11_4_402_278!unuse_netscape_plugin_Plugin+0x11de9 (5623f607)
562460d2 5e              pop     esi
562460d3 c20400          ret     4

I'd like to make it clear this is not a software vulnerability.