lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <4C61B2F4.5080603@coresecurity.com>
Date: Tue, 10 Aug 2010 17:13:40 -0300
From: CORE Security Technologies Advisories <advisories@...esecurity.com>
To: Bugtraq <bugtraq@...urityfocus.com>, 
 full-disclosure@...ts.grok.org.uk
Subject: CORE-2010-0407: Microsoft Office Excel PivotTable
 Cache Data Record Buffer Overflow

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

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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkxhsvMACgkQyNibggitWa3SZQCeIQ9oxM48E4FXX2yxcKW+XFts
1jMAoKvDR2SVz6mTGp7S44g5s9AMQlx7
=Z2wt
-----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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ