Microsoft Office Excel PivotTable Cache Data Record Buffer Overflow

Core Security - CoreLabs

Microsoft Office Excel PivotTable Cache Data Record Buffer Overflow

1. Advisory Information

Title: Microsoft Office Excel PivotTable Cache Data Record Buffer Overflow
Advisory Id: CORE-2010-0407
Advisory URL: http://www.coresecurity.com/content/CORE-2010-0407-Excel-PivotTable-CDR-overflow
Date published: 2010-08-10
Date of last update: 2010-08-09
Vendors contacted: Microsoft
Release mode: Coordinated release

2. Vulnerability Information

Class: Buffer Overflow [CWE-119]
Impact: Code execution
Remotely Exploitable: Yes (client-side)
Locally Exploitable: No
CVE Name: CVE-2010-2562
Bugtraq ID: 42199

3. Vulnerability Description

A stack based buffer overflow vulnerability in Microsoft Excel 2002 (Office XP) can be leveraged to execute arbitrary code on vulnerable systems by enticing users to open specially crafted spreadsheet files with the .XLS extension. The vulnerability results from improper parsing of a PivotTable Cache Data record. 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

  • Microsoft Excel 2002 (Office XP SP3).

5. Non-vulnerable packages

  • Microsoft Office 2003.
  • Microsoft Office 2007.
  • Microsoft Office 2010.

6. Vendor Information, Solutions and Workarounds

Refer to the Microsoft bulletin "Vulnerability in Microsoft Office Excel Could Allow Remote Code Execution".
http://go.microsoft.com/fwlink/?LinkID=196275&clcid=0x409

7. Credits

This vulnerability was discovered by Damian Frizza from Core Security Technologies.

8. Technical Description / Proof of Concept Code

A stack-based buffer overflow can be triggered when Excel XP parses a .XLS file with a crafted PivotTable Cache Data Record (offset C6h). The vulnerability occurs if the member cfdbTot has a value equal to 0. Modifying this record allows an exploitable condition to be triggered as shown in the following dissassembly of the vulnerable code:

30013CD4   . 0FB707         MOVZX EAX,WORD PTR DS:[EDI] 	;invalid pointer **
30013CD7   . 56             PUSH ESI
30013CD8   . 8D3400         LEA ESI,DWORD PTR DS:[EAX+EAX] 	;size = content*2
30013CDB   . F7C6 00000080  TEST ESI,80000000
30013CE1   . 0F85 2D642300  JNZ EXCEL.3024A114
30013CE7   > 83C7 02        ADD EDI,2
30013CEA   . 56             PUSH ESI 				;size
30013CEB   . 57             PUSH EDI 				;src
30013CEC   . 8B7C24 14      MOV EDI,DWORD PTR SS:[ESP+14]	;stack buffer
30013CF0   . 57             PUSH EDI 				;dst
30013CF1   . E8 8228FFFF    CALL EXCEL.30006578                 ;copy to stack

EAX 0013F288
ECX 00000000
EDX 00012BB8
EBX 0000110A
ESP 0013F06C
EBP 0013F590
ESI 00003000
EDI 08E06938 **

 

By allocating at the address referenced by the invalid pointer at 30013CD4 it is possible to control the contents of the src pointer pushed at 30013CEB and the number of bytes to copy pushed at 30013CEA allowing the execution of arbitrary code after the copy operation at 30013CF1 overruns the destination buffer in the stack.

This exploitable condition was reproduced in the following versions of the executables:

  • EXCEL.exe version 10.0.6501
  • EXCEL.exe version 10.0.6854
  • EXCEL.exe version 10.0.6856
  • EXCEL.exe version 10.0.6860

9. Report Timeline

  • 2010-04-16: Initial notification to the vendor. Draft advisory and proof-of-concept files sent to MSRC. Publication date set for May 10, 2010.
  • 2010-04-19: MSRC responds that case 9975cw has been opened.
  • 2010-04-27: New case manager assigned by MSRC to handle the case. The issue is still being investigated.
  • 2010-04-30: Vendor concluded the investigation and confirmed that its is an exploitable issue that can allow remote code execution. A security bulletin will be issued to address the issue at a date not yet determined.
  • 2010-05-04: Core acknowledges receipt of the previous email, and communicates that in the meantime Core has re-scheduled the publication of the advisory to June 8th, 2010.
  • 2010-05-13: Core requests an update about the status of this case noting that the last communication was received 13 days ago.
  • 2010-05-15: Vendor says that it was not able to complete the required testing for the fix to be included in the June patch release; indicates that it is now agressively targeting the release of a fix for October; and requests that Core postpones publication of the corresponding advisory until then. Vendor also requests a copy of the advisory that Core plans to publish.
  • 2010-05-17: Core responds that the request will be discussed at the next weekly meeting of the security advisories team; but that the viewpoint of Core's case handler is that postponing the release of fixes and advisory publication to October is well beyond what is considered acceptable for a timely release of a fix for a simple and yet exploitable file format bug. Given that the bug was first reported to the vendor on April 16th 2010 publication of the fix and the advisory in the October patch release would mean, in the best case scenario, a minimum timespan of 6 months and missing 5 consecutive patch Tuesdays. This being well beyond what Core would expect from a large software vendor seen as having the most mature and sophisticated SDLC.
  • 2010-05-27: Core informs that the publication date for the advisory has been postponed to July 13th 2010. Core understands that the new date does not match the proposal from MSRC; but considers that it is reasonable to expect fixes, for a simple and clearly exploitable bug in Office, within 3 patch release cycles (May, June and July) of the original report. Should the vendor have problems targeting July as the release date for fixes, Core is open to discuss other available options including release of a vendor advisory and/or workarounds.
  • 2010-05-28: Vendor acknowleges receipt of the previous mail.
  • 2010-06-01: Vendor requests a conference call to discuss this case.
  • 2010-06-01: Core asks about the agenda for the conference call; whether it will be to discuss technical matters about the bug or to negotiate the disclosure timeline.
  • 2010-06-01: Vendor responds that the discussion will only concern the disclosure timeline.
  • 2010-06-01: Core confirms time and date for the conference call.
  • 2010-06-03: Vendor requests from Core an updated version of the advisory draft.
  • 2010-06-04: Core sends the updated advisory.
  • 2010-06-08: Vendor acknowledges receipt of the advisory.
  • 2010-06-23: Core requests an update about this report, and asks the vendor whether it is still targeting the release of a patch in October at the earliest.
  • 2010-06-25: Vendor responds that it is now working agressively to ship a patch for this issue on August 8th, 2010; and asks Core whether that would be an acceptable timeline for a coordinated disclosure.
  • 2010-06-25: Core agrees to postpone publication of its advisory to August 10th, 2010; and communicates that the new publication date is final.
  • 2010-06-28: Vendor thanks Core for its cooperation and support.
  • 2010-07-12: Vendor communicates that it is still on track to release a patch for this issue on August 8th, 2010; and asks Core whether the credits line for its bulletin is correct.
  • 2010-07-22: Core confirms that it is also on track to publish its advisory on August 8th, 2010; that the credits paragraph is correct; and that another member of the advisories team will continue handling this case.
  • 2010-07-23: Vendor acknowledges receipt of previous mail.
  • 2010-07-29: Core asks the vendor if a CVE number has been assigned for this vulnerability, and if the vendor wants to include a vendor statement in the advisory.
  • 2010-08-03: Core reminds the vendor of the previous mail, and sends an updated version of the advisory CORE-2010-0407.
  • 2010-08-03: Vendor replies with the CVE number assigned, and a link to its security bulletin [1]
  • 2010-08-10: Advisory CORE-2010-0407 is published.

10. References

[1] Microsoft bulletin "Vulnerability in Microsoft Office Excel Could Allow Remote Code Execution"
http://go.microsoft.com/fwlink/?LinkID=196275&clcid=0x409

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

13. 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/

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
  • Request Info

Research Blog