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
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.
- Microsoft Publisher 2007 (12.0.6546.5000)
Contact the vendor for information concerning a fix for this vulnerability.
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.
This vulnerability was discovered and researched by Daniel Kazimirow from Core Security Technologies.
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 .
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
- 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 
- 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:
- 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.
 How to troubleshoot a damaged publication in Publisher
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.
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.
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/
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.