AOH :: HP Unsorted A :: BT-21577.HTM

Autonomy KeyView Excel File SST Parsing Integer Overflow Vulnerability



iDefense Security Advisory 08.25.09: Autonomy KeyView Excel File SST Parsing Integer Overflow Vulnerability
iDefense Security Advisory 08.25.09: Autonomy KeyView Excel File SST Parsing Integer Overflow Vulnerability



iDefense Security Advisory 08.25.09
http://labs.idefense.com/intelligence/vulnerabilities/ 
Aug 25, 2009

I. BACKGROUND

Autonomy KeyView SDK is a commercial SDK that provides many file format
parsing libraries. It supports a large number of different document
formats, one of which is the Microsoft Excel 97 (XLS) format. It is
used by several popular vendors for processing documents. For more
information, visit the URL referenced below.

http://www.autonomy.com/ 

KeyView is used by many commercial products to handle various types of
file formats. Lotus Notes and Symantec Mail Security are two examples
of such products.

II. DESCRIPTION

Remote exploitation of an integer overflow vulnerability in Autonomy's
KeyView SDK allows attackers to execute arbitrary code with the
privileges of the targeted application.

The vulnerability occurs when parsing a Shared String Table (SST) record
inside of an Excel file. This record is used to hold a table of strings
that are used inside of the document. One of the fields in this record
is a 32-bit integer that represents the number of strings in the table.
This value is used in a calculation that controls the number of bytes to
allocate for a dynamic heap buffer. The value is not properly sanitized,
which leads to an integer overflow in the calculation. This results in a
heap based buffer overflow vulnerability.

III. ANALYSIS

Exploitation allows attackers to execute arbitrary code with the
privileges of the targeted application. In order to exploit this
vulnerability, an attacker must cause a specially crafted Microsoft
Excel Spreadsheet to be processed by an application using the Autonomy
KeyView SDK.

When targeting applications like Lotus Notes, this requires that an
attacker convince a user to view an e-mail attachment; however, in
other cases, processing may take place automatically as a document is
examined. The specific circumstances will depend on the application
being targeted.

The privileges that an attacker gains may be different for each
application that uses the KeyView SDK. For example, exploiting this
issue via Lotus Notes yields the current user's privileges while
exploiting the vulnerability via Symantec Mail Security yields SYSTEM
privileges.

IV. DETECTION

iDefense confirmed the existence of this vulnerability using the
following versions of the affected software:

  xlssr.dll version 8.0.0.7214, distributed with IBM Lotus Notes 8.0
  xlssr.dll version 8.5.0.8339, distributed with IBM Lotus Notes 8.5
  xlssr.dll version 10.5.0.0, distributed with Symantec Mail Security
for Microsoft Exchange

All versions of the KeyView SDK that include the "xlssr.dll" filter
module are suspected to be vulnerable.

V. WORKAROUND

For all products using the KeyView SDK, you can disable the "xlssr.dll"
filter by doing one of the following:

  Removing the xlssr.dll filter module from the affected system(s).
  Delete or comment out the line referencing "xlssr.dll" from the
"KeyView.ini" file distributed with the affected application.

Additionally, for Symantec Mail Security, disabling "content filtering"
will prevent exploitation.

VI. VENDOR RESPONSE

IBM has released a patch which addresses this issue in Lotus Notes. For
more information, consult their advisory at the following URL:

http://www-01.ibm.com/support/docview.wss?rs=463&uid=swg21396492 

Symantec has released a patch which addresses this issue in several
Symantec products. For more information, consult their advisory at the
following URL:

http://www.symantec.com/business/security_response/securityupdates/detail.jsp?fid=security_advisory&pvid=security_advisory&year=2009&suid=20090825_00 

VII. CVE INFORMATION

A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not
been assigned yet.

VIII. DISCLOSURE TIMELINE

05/05/2009  - Initial Contact
05/05/2009  - Autonomy first response
05/05/2009  - Symantec first response
05/05/2009  - IBM first response
05/05/2009  - Autonomy POC request
05/05/2009  - IBM POC request
05/06/2009  - Autonomy clarification request
05/06/2009  - Symantec clarification request
05/06/2009  - Request public key from Autonomy
05/06/2009  - Sent POC to IBM, Symantec
05/06/2009  - Symantec requests resend
05/06/2009  - Resent POC to Symantec
05/06/2009  - Autonomy sends public key
05/06/2009  - Sent POC to Autonomy
05/07/2009  - Symantec holding on Autonomy fix
05/07/2009  - Autonomy requested clarification
05/07/2009  - Sent clarification.
08/11/2009  - Disclosure coordination
08/17/2009  - Disclosure re-coordination
08/25/2009  - Coordinated Public Disclosure

IX. CREDIT

This vulnerability was discovered by Joshua J. Drake of iDefense Labs.

Get paid for vulnerability research
http://labs.idefense.com/methodology/vulnerability/vcp.php 

Free tools, research and upcoming events
http://labs.idefense.com/ 

X. LEGAL NOTICES

Copyright =A9 2009 iDefense, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDefense. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically,
please e-mail customerservice@idefense.com for permission. 

Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
 There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct,
indirect, or consequential loss or damage arising from use of, or
reliance on, this information.

The entire AOH site is optimized to look best in Firefox® 3 on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH
We do not send spam. If you have received spam bearing an artofhacking.com email address, please forward it with full headers to abuse@artofhacking.com.