Date: Tue, 23 Mar 1999 18:57:23 +0100
From: Martin Bartosch <bartosch@MAIL.DEUBA.COM>
To: BUGTRAQ@netspace.org

                          Security advisory

                    Advisory released Mar 23 1999

                                -----

             Application: Lotus Notes Client (Version 4.5, probably others)

                  Impact: Encrypted mail sent from the Notes client may
                          traverse the network in the clear and may be stored
                          on the mail server unencrypted.

                  Author: Martin Bartosch

                                -----


Synopsis
--------

When performing network analysis experiments with the Lotus Notes Client
a very subtle bug was discovered that may lead to inadvertent revelation of
confidential information.

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.

Lotus is currently working on the problem, a detailed analysis and official
fixes may be available soon. Once this is available, it should be preferred
to the workaround presented in this document.


Details
-------

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.


Workaround
----------

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.



Vendor activities
-----------------

Lotus has been informed of this bug and is currently working on the problem.
An official fix or workaround will be published by Lotus.



Credits
-------

Michael Doberenz; Michael Popp
  whose network analysis experiments revealed that there was a problem
  in the first place

Artur Hahn
  found the real reason (path separator issue) for the Notes encryption
  problem





--
Martin Bartosch                                       bartosch@mail.deuba.com

This message and any statements expressed therein are those of myself
and not of the Deutsche Bank AG or its subsidiary companies.

------------------------------------------------------------------------------

Date: Wed, 24 Mar 1999 08:30:04 +0100
From: IAKOVLEV@FR.IBM.COM
To: BUGTRAQ@netspace.org
Subject: Re: LNotes encryption

Hello,

 Do you want to say that if you use only the backslashes in the path to the
mailbox (ex. mail\path\to\user.nsf)
and DO NOT check the "Encrypt saved mail" box, the saved mail will still be
encrypted?

 It is reasonable to expect that if you do not check the "Encrypt saved
mail" box, the respective message is stored in clear in the mail database,
and as such is recoverable via sniffing the network traffic, be it the
initial mail copy storing on the remote server, or any replication (via the
network) of the database, unless you encrypt the network traffic, by
checking the respective box in the File -> Tools -> User Preferences ->
Ports menu.

Regards.

A. Iakovlev.

------------------------------------------------------------------------------

Date: Fri, 26 Mar 1999 10:24:06 +0100
From: Martin Bartosch <bartosch@MAIL.DEUBA.COM>
To: BUGTRAQ@netspace.org
Subject: Lotus Notes Encryption Bug

IAKOVLEV@FR.IBM.COM wrote:

>  Do you want to say that if you use only the backslashes in the path to
> the mailbox (ex. mail\path\to\user.nsf) and DO NOT check the "Encrypt
> saved mail" box, the saved mail will still be encrypted?

Yes - if the product functions correctly AND if you select "encrypt mail"
in the mail options while composing the new mail note. As far as I can
verify this, the saved mail stored in the "Sent mail" folder is encrypted
when these conditions are met - even if "encrypt saved mail" and "encrypt
sent mail" are NOT checked.

>  It is reasonable to expect that if you do not check the "Encrypt saved
> mail" box, the respective message is stored in clear in the mail
> database, and as such is recoverable via sniffing the network traffic,
> be it the initial mail copy storing on the remote server, or any
> replication (via the network) of the database, unless you encrypt the
> network traffic, by checking the respective box in the File -> Tools ->
> User Preferences ->Ports menu.

I disagree: when a user composes a mail and specifically requests
encryption for this mail she has good reason to believe that the product
will not pass any clear text of this message over the wire or store plain
text on external systems - regardless of any global settings elsewhere.

In my opinion it is reasonable to expect that if I request encryption by
*any* means within the client, I do not want the clear text to leak out.
And I wish to be told about any problems if my software cannot perform
this action properly for some reason.

In addition I do not think that the "enrypt network traffic" option does
help a lot - the message is still stored on the server in the plain.


Regards,

Martin

--
Martin Bartosch                                       bartosch@mail.deuba.com

This message and any statements expressed therein are those of myself
and not of the Deutsche Bank AG or its subsidiary companies.

-------------------------------------------------------------------------------

Date: Mon, 29 Mar 1999 22:20:19 +0200
From: IAKOVLEV@FR.IBM.COM
To: BUGTRAQ@netspace.org
Subject: Re: Lotus Notes Encryption Bug

> >  Do you want to say that if you use only the backslashes in the path to
> > the mailbox (ex. mail\path\to\user.nsf) and DO NOT check the "Encrypt
> > saved mail" box, the saved mail will still be encrypted?
>
> Yes - if the product functions correctly AND if you select "encrypt mail"
> in the mail options while composing the new mail note. As far as I can
> verify this, the saved mail stored in the "Sent mail" folder is encrypted
> when these conditions are met - even if "encrypt saved mail" and "encrypt
> sent mail" are NOT checked.

Well, I have just checked this with my setup : a "no connection" location,
with a plain file name (without directories prepended) for the mailfile,
with "encrypt saved mail" and "encrypt sent mail" unchecked.

My client (4.53b for France) indeed says (on the status bar) that it is
encrypting the message with my private key, but the result is that the
saved message is NOT encrypted...

Then, with both "encrypt saved mail" and "encrypt sent mail" checked, the
behaviour is the same...

I would conclude that there are other cases (client versions, mail
templates, usage cases etc.), beyond those already identified, provoking
this bug, and I hope Lotus will help us to sort it out (right, Kevin? :-)


> >  It is reasonable to expect that if you do not check the "Encrypt saved
> > mail" box, the respective message is stored in clear in the mail
> > database, and as such is recoverable via sniffing the network traffic,
> > be it the initial mail copy storing on the remote server, or any
> > replication (via the network) of the database, unless you encrypt the
> > network traffic, by checking the respective box in the File -> Tools ->
> > User Preferences ->Ports menu.
>
> I disagree: when a user composes a mail and specifically requests
> encryption for this mail she has good reason to believe that the product
> will not pass any clear text of this message over the wire or store plain
> text on external systems - regardless of any global settings elsewhere.

I agree, from the intuitive basic user point of view, there's or there's
not "encryption".
Now with all the checkboxes provided by the product, a technical person
should suspect that there could be multiple possible ways for the product
to operate. It is a design decision, and it is up to the authors of the
product to chose which buttons and whistles to provide, and what hidden
logic to implement.

But when the thing says it is encrypting and it is not, it is a clear BUG.

Then, the mail server is not clearly an external system ; in a corporate
environment, for example, the mail clients and servers are both part of the
internal information system, and usually there is no privacy boundary
between the two. If you wish to be really independent of the server's
security, there would be more steps to make : you'll have to distribute
your public key by a third means, you'll have to ensure that all the
incoming mail is encrypted, as well as some other things. But then you'll
have to know the product very well, to the point that you have checked that
all the features you need work as expected...



> In my opinion it is reasonable to expect that if I request encryption by
> *any* means within the client, I do not want the clear text to leak out.
> And I wish to be told about any problems if my software cannot perform
> this action properly for some reason.
>
> In addition I do not think that the "enrypt network traffic" option does
> help a lot - the message is still stored on the server in the plain.
>

It addresses a particular threat, the network sniffing. It is useful for
retrieving unencrypted incoming mail or for accessing any other unencrypted
data on the server, where the other encryption features (private/public key
encryption) cannot be employed.


A. Iakovlev
---------------------------------------------------------------------------
---------
The statements and opinions expressed in this message are not
and do not necessarily correspond to those of IBM Corporation.