Microsoft Publisher 2007 Pubconv.dll Memory Corruption

Core Security Technologies - Corelabs Advisory


Microsoft Publisher 2007 Pubconv.dll Memory Corruption

1.
Advisory Information

Title: Microsoft Publisher 2007 Pubconv.dll Memory Corruption
Advisory ID: CORE-2011-0106
Advisory URL: http://www.coresecurity.com/content/publisher-pubconv-memory-corruption
Date published: 2011-10-12
Date of last update: 2011-10-11
Vendors contacted: Microsoft
Release mode: User release

2.
Vulnerability Information

Class: Input validation error [CWE-20]
Impact: Code execution
Remotely Exploitable: Yes (client-side)
Locally Exploitable: No
CVE Name: CVE-2011-1508

3.
Vulnerability Description

Microsoft Publisher is a desktop publishing application from Microsoft that uses a proprietary file format (.pub). A vulnerability has been found in Publisher 2007, that can be leveraged by an attacker to execute arbitrary code by enticing users to insert a specially-crafted .pub file into a document.

4.
Vulnerable packages

  • Microsoft Publisher 2007 (12.0.6546.5000)

5.
Non-vulnerable packages

Contact the vendor for information concerning a fix for this vulnerability.

6.
Vendor Information, Solutions and Workarounds

Contact the vendor for information concerning a fix for this vulnerability. As a generic mitigation, don't open or paste into the Publisher program publications from untrusted sources.

7.
Credits

This vulnerability was discovered and researched by Daniel Kazimirow from Core Security Technologies.


8.
Technical Description / Proof of Concept Code

By enticing a Microsoft Publisher user to insert a specially-crafted .pub file into a document, an attacker could leverage this vulnerability to gain execution of arbitrary native code. Note that pasting a publication into the Publisher program is one of the recommended ways to troubleshoot a damaged publication in Publisher [1].

By modifying the .pub file it is possible to make the pubconv.dll library copy enough content from the file to the stack so as to overwrite a function pointer that is later executed by the library.

As shown in the following extract from PubConv.dll, the call to function sub_344EEB00 (1.1) returns a pointer to a WORD with the size of the data to be copied from an intermediate buffer to the stack. Instruction (1.2) shows that ECX is loaded with that 16-bit value sign-extended to 32 bits. This value, after a series of verifications and transformations, is used in (1.3) as the size argument of a memmove call. This ends up writing a function pointer in the stack.

       
34530EDC    push    ebp
34530EDD    mov     ebp, esp
34530EDF    push    esi
34530EE0    mov     esi, [ebp+arg_0]
34530EE3    push    edi
34530EE4    push    esi
34530EE5    call    sub_344EEB00            <---(1.1)---
34530EEA    mov     edi, eax
34530EEC    movzx   ecx, word ptr [edi+4]   <---(1.2)---
...
...
...
34530F1C    movsx   eax, ax
34530F1F    add     ecx, edi
34530F21    lea     esi, [ecx+edx*4+16h]
34530F25    mov     ecx, [ebp+Dst]         
34530F28    push    eax             ; Size  <---(1.3)---
34530F29    push    esi             ; Src
34530F2A    push    ecx             ; Dst
34530F2B    mov     dword_3456CB6E, ecx
34530F31    call    memmove                 <---(1.4)---
...

Later, this function pointer, which can be controlled by the attacker, is called during normal execution flow; therefore the attacker can control the execution flow at instruction (2.1) in the extract from PubConv.dll below.

050128D8    push    ebp
050128D9    mov     ebp, esp
050128DB    push    esi
050128DC    mov esi, [ebp+arg_0]
050128DF    mov eax, dword ptr [esi+8]
050128E2    test eax, eax
050128E4    je short SKIP_MY_CALL
050128E6    mov ecx, dword ptr ds:[EAX] 
050128E8    push eax
050128E9    call dword ptr [ecx+8]    <---(2.1)---
050128EC    and dword ptr [esi+8],0
:SKIP_MY_CALL

>

9.
Report Timeline

  • 2011-03-22: Initial notification from Core to MSRC team, including technical details. The advisory ID is CORE-2011-0106, and the tentative publication date is set to April 18, 2011.
  • 2011-03-22: MSRC acknowledges receipt of the advisory draft, and requests a confirmation of the Publisher version number tested.
  • 2011-03-22: Core clarifies that the version of Publisher 2007 tested is 12.0.6546.5000, and that the vulnerability researcher is able to reproduce the crash by inserting the .pub PoC file in a blank publisher document as described in [1]
  • 2011-03-23: MSRC acknowledges receipt of the additional information, and informs that the issue is tracked as MSRC case 11079.
  • 2011-03-29: Vendor informs that it is still investigating the issue.
  • 2011-03-30: Core acknowledges receipt of the previous mail.
  • 2011-04-05: Vendor requests additional information: (i) a Watson bucket ID from the crash, and (ii) whether the following registry key was set: [HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Publisher] "PromptForBadFiles"=dword:00000001.
  • 2011-04-06: Core provides the bucket ID and responds that the registry key wasn't set while reproducing the issue.
  • 2011-04-11: Core asks the vendor whether the additional information has been received.
  • 2011-04-11: Vendor confirms the receipt of the requested information, and states that it is still investigating the issue based on the provided information.
  • 2011-04-12: Vendor completed its investigations, and confirms that the crash could be exploited to execute arbitrary code. Vendor states that in order to exploit the vulnerability, an attacker would have to convince the user through social engineering to insert a Publisher file into another Publisher file. Since this is not a common usage scenario and because of the social engineering required and the risk posed to customers, the vendor believes the severity of this issue is Moderate. The vendor evaluates that this issue does not warrant an out of band (OOB) release, and requests Core to postpone publication until fixes can be issued as part of a regular Patch Tuesday release.
  • 2011-04-13: Core agrees with the vendor's analysis of the impact and the severity of this issue. Core agrees to reschedule publication to better fit in the vendor's release process.
  • 2011-04-13: Vendor acknowledges Core's support, and states that it will keep Core updated on the release date.
  • 2011-04-25: Core requests an update on the publication date of fixes, and reschedules publication of its advisory to May 10th, 2011.
  • 2011-04-26: Vendor informs that it has tentatively scheduled this case for a bulletin release on August 9, 2011, and is actively targeting this date. Vendor requests Core to hold off on the advisory publication until fixes are released.
  • 2011-05-02: Core agrees to reschedule the publication of its advisory for August 9, 2011. Core requests the vendor to send regular updates concerning the development and testing of fixes (at least once per month).
  • 2011-05-02: Vendor acknowledges Core's support, and states that it will provide updates once a month on the status of this issue.
  • 2011-06-09: Core requests an update on this issue, and a list of affected versions.
  • 2011-06-10: Vendor communicates that it will provide the requested information the following week.
  • 2011-06-16: Core requests (again) an update on this issue.
  • 2011-06-17: Vendor confirms that it is still on track to release the update for this issue on August 9, 2011.
  • 2011-06-30: Core acknowledges receipt of the update, and asks whether a CVE id has been assigned to this vulnerability.
  • 2011-07-05: Vendor responds that CVE-2011-1972 has been assigned to this case.
  • 2011-07-28: Vendor informs that it ran into a large regression testing the package containing the fix for this issue and some other Publisher cases. Vendor states that it is targeting October 11, 2011, as the new release date and that it will keep Core updated on the status. The vendor requests Core to hold off on its advisory release until October 11.
  • 2011-07-29: Core asks the vendor why the new target date (October 11) is two months after the current one (August 9). Core also states that October is beyond the 6-months limit that it considers acceptable for the release of fixes for this kind of issue.
  • 2011-08-01: The vendor provides additional information about the testing and release process, and requests Core to make an exception to the 6-months limit, since the release of the October patch is just a few days after the deadline.
  • 2011-08-04: Core agrees to postpone (again) the publication of its advisory to October 11, 2011, and informs the vendor that this date should be considered final.
  • 2011-08-08: Vendor acknowledges Core's decision and support.
  • 2011-10-07: Core asks the vendor whether fixes for this vulnerability will be effectively released on October 11 (no reply received).
  • 2011-10-12: The advisory CORE-2011-0106 is published as user release. The CVE-2011-1508 identifier is assigned to this vulnerability, since the CVE id provided by the vendor is associated with vulnerabilities in Microsoft Visio fixed in Microsoft Security Bulletin MS11-060, released on August 9, 2011.

10.
References

[1] How to troubleshoot a damaged publication in Publisher
http://support.microsoft.com/default.aspx?scid=kb;en-us;198256

11.
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.

12.
About Core Security Technologies

Core Security Technologies enables organizations to get ahead of threats with security test and measurement solutions that continuously identify and prove real-world exposures to their most critical assets. Our customers can gain real visibility into their security standing, real validation of their security controls, and real metrics to more effectively secure their organizations.

Core Security's software solutions build on over a decade of trusted research and leading-edge threat expertise from the company's Security Consulting Services, CoreLabs and Engineering groups. Core Security Technologies can be reached at +1 (617) 399-6980 or on the Web at: http://www.coresecurity.com.

13.
Disclaimer

The contents of this advisory are copyright (c) 2011 Core Security Technologies and (c) 2011 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/

14.
PGP/GPG Keys

This advisory has been signed with the GPG key of Core Security Technologies advisories team, which is available for download at /legacy/files/attachments/core_security_advisories.asc.

Locally Exploitable: 
no
Remotely Exploitable: 
no
  • Book Demo

Research Blog