[Full-disclosure] CORE-2011-0106: Microsoft Publisher 2007 Pubconv.dll Memory Corruption

[CORE Security Technologies Advisories <advisories@xxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

    Core Security Technologies - Corelabs Advisory
         http://corelabs.coresecurity.com/

    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
http://www.coresecurity.com/files/attachments/core_security_advisories.asc.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iEYEARECAAYFAk6Vy/QACgkQyNibggitWa2TvgCgma9wKGM0AtLP5zxwjHVnUjXr
P0UAn2l4X7d9JJm9JYa+lAYG1hPPYl4w
=wGj/
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/