Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!

 TUCoPS :: IBM(multi) :: notes04.htm Lotus Notes - encrypted mail may traverse the network in the clear

Vulnerability

Lotus Notes

Affected

Lotus Notes Client (Version 4.5, probably others)

Description

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
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.


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).