COMMAND
Lotus Notes
SYSTEMS AFFECTED
Lotus Notes Client (Version 4.5, probably others)
PROBLEM
Following is based security advisory by Martin Bartosch.
Encrypted mail sent from the Notes client may traverse the network
in the clear and may be stored on the mail server unencrypted.
Usually the Notes client sends at least two copies of a newly
created mail. One copy is sent to the recipient, the other is
stored in the "Sent Mail" folder of the sender's Notes server.
If an encrypted mail is to be sent and the conditions for this bug
are met, the copy for the sender's "Sent Mail" folder is not
encrypted. As a result, the message is sent to the Notes server in
the clear and stored on the Notes server unencrypted. The message
may thus be intercepted and read by analyzing the network traffic
between the sender's Notes client and the server or by directly
accessing the "Sent Mail" folder on the Notes server. The user is
not given any warning or notification about the problem, and the
problem causes almost no noticable side effects. As a result, if
a user is affected by the problem, this will probably remain
unnoticed. Credit goes also to Michael Doberenz and Michael Popp
whose network analysis experiments revealed that there was a
problem in the first place and Artur Hahn who found the real
reason (path separator issue) for the Notes encryption problem.
The problem seems to result from an inadequate check condition in
the client code. Traditionally Windows, DOS and OS/2 use the
backslash character ('\') as a path separator, whereas Unix
systems use the slash ('/') for this purpose. Applications that
deal with both styles need to be aware of the problem and have to
take care of paths passed to applications or services on other
systems. The user's database usually is located on a remote
server. Though Notes clients are normally Windows style systems,
the servers may either run Windows, OS/2 or Unix as the server
operating system. Thus Notes needs to take care of proper
translation of file paths as files are accessed on various
platforms. Notes accesses databases by specifying the server and
the path to the database. In order to open a user's database in
the first place, the user needs to enter the correct path to the
database or traverse the directory tree on the server. When the
database has been opened, Notes remembers the path to the database
for subsequent access to this database. Internally the Notes
client seems to store the path to the database using the client
operating system file naming conventions. In particular, on
Windows or OS/2 platforms, Notes uses Backslash characters ('\')
as path separators. The current Notes environment settings may be
changed by opening the environment document (File/Mobile/Edit
current environment). In the second entry of the section "Mail"
the path to the mail file can be changed by the user. Notes uses
this entry for various purposes. One of these is the periodical
check for new mail or agenda events. (If the user specifies an
incorrect path here, mail notification does not work any longer.)
To address the backslash-slash problem, Notes seems to translate
any path entered by the user into the proper representation needed
for accessing the service required. Apparently it does not matter
at all if paths are entered with slashes or backslashes as path
separators. The GUI dialogs accept any spelling as well as the
environment document mentioned above. However, if for some reason
the environment document of a Windows style client specifies the
mail file with *slashes* as a path separator (like e. g.
mail/users/user.nsf instead of mail\users\user.nsf) Notes does a
proper translation of the path and almost all functions will work
as expected. Except for one side effect: Notes does not recognize
the specified database as the user's mail database. Probably a
simple string compare between the currently opened mail database
and the database path of the environment document is performed,
and this comparison fails because of the different representation
of paths. The resulting effect: if an encrypted mail is to be
sent and the environment document does contain a mail database
path with 'incorrect' path separators as seen from the client OS
view, the mail copy for the user's "Sent Mail" folder is being
sent to the user's database in the plain and stored unencrypted on
the server. The contents of the message may be read in plain text
by sniffing on the network or by directly accessing the notes
database. The behaviour described can be reproduced with almost
any Notes client and server combination. Even if both the server
and client use the same operating system, it is still possible to
enter the mail path separated with slash characters. The Notes
client will behave as described above.
Detection:
- compose a new mail message
- address this message to some other user
- using the mail properties dialog enable encryption for this
individual message
- send message
- change to the "Sent Mail" folder of your mail database
- right-click on the sent message once
- open the properties dialog for this document
- choose "fields" in the document properties
- check existence of the fields "$Seal", "$SealData" and "Body"
Under normal circumstances the "$Seal"/"$SealData" and "Body"
fields are mutually exclusive. The existence of "$Seal" and
"$SealData" usually indicate that the message was properly
encrypted. If the field "Body" exists, this message is stored in
the plain on the server and was transferred unencrypted across the
network. Alternatively the network traffic can be analyzed while
sending an encrypted mail. This is how the bug was discovered in
the first place.
SOLUTION
The bug only occurs when the Notes client is misconfigured, but it
is not an unlikely misconfiguration and it has few if any other
symptoms. Until the problem is fixed in a future release of the
software, users are encouraged to consider whether the problem is
likely to affect them and if so check for the misconfiguration.
To ensure that your email is saved in encrypted form, Lotus
recommends using backslashes (\) as path separator in the Mail
File field of the user's Location Document (in both Personal and
Public Address Book) and by selecting "Encrypt Saved Mail"
in User Preferences.
Lotus is currently working on the problem, a detailed analysis
and official fixes may be available soon. The workaround
described here may be an incomplete fix for the problem; the
problem may be triggered by other conditions as well. As Lotus
is actively investigating on the problem, the solution presented
by Lotus may be more general and should be preferred once it is
available.
First method:
=============
Open your environment document. The path to the database must
*not* contain any path separator characters that are not natively
used by the client operating system. When using a Windows or OS/2
environment, the path must only contain backslash '\' characters.
Example:
Mail File: mail\path\to\user.nsf * OK *
Mail File: mail/path/to/user.nsf * DANGER! *
A client restart is required to make the changes effective.
Second method:
==============
In your global preferences check the "Encrypt saved mail" box.
Every message you send will be encrypted when saving the message
to the "Sent Mail" folder on the server. Use both methods to be
sure that mail sent by the client is not sent and stored in the
clear. Be aware that using the second methond will result in
encryption of the whole database and that loss of your passphrase
or Notes ID will effectively cause loss of your mail database
contents.