COMMAND
Outlook 98
SYSTEMS AFFECTED
Win plaforms
PROBLEM
Russ Cooper found following. This problem describes issues with
the Protected Storage subsystem in NT and Win9x, and in
particular, its use with S/MIME and Outlook '98.
A user has obtained a Digital Certificate from Verisign to use
with S/MIME, and during installation, has chosen to set their
security level to "Medium" (which means that each time their
certificate is used, a dialog will appear informing them). Said
certificate can be used to both digitally sign, and encrypt, a
message sent from Outlook '98.
After creating a message and setting the options to sign and
encrypt, the user presses the "Send" button. The message window
closes and the Protected Storage dialog appears informing them of
the use of their certificate. The dialog has 3 buttons and an "X"
to close it. "Ok", "Cancel", and "Details". The message is not
acted on until this dialog is closed by clicking "Ok", "Cancel",
or the "X". Based on the presentation of a "Cancel" button, the
user decides (for whatever reason) that the action should not be
completed. The natural assumption is that the message will not be
sent. The problem is that message is sent, and what's worse, by
clicking on the cancel button, the message is sent without
encryption.
What happens is that the request to apply the digital certificate
(and then use that mechanism to encrypt the message) is completely
cancelled, but the message gets sent anyway. The targeted
recipients will receive a message that appears to have a digital
certificate (they will see a little blue ribbon icon beside the
message), but when they open it a dialog will appear indicating a
problem with the signature of the message. This dialog lists a
variety of information about the signing of the message that is
supposed to be based on the presence of an actual signature.
However, since the sender cancelled the use of their signature,
no certificate is actually attached. The receiver is told, for
example, that the message;
- The signature is invalid
*this makes sense, it was never signed)
- The message is digitally signed
*yet it isn't
- The contents were not altered after it was signed
*it was never signed, so how does it know this?
- The certificate is not revoked
*it was never signed, so how does it know this?
- The certificate is not expired
*it was never signed, so how does it know this?
- The certificate is trusted
*it was never signed, so how does it know this?
- Email address on certificate is same as sender's address
*it was never signed, so how does it know this?
- There are other failure reasons
*When there are other failure reasons Outlook states "You can
look at the problems with the certificate by selecting View
Certificate", but the View Certificate button is grayed because
there was no certificate!
To top that off, Outlook has a View Message button on this dialog.
When you click that button Outlook displays the message that was
sent, unencrypted.
The risks here should be obvious. When the original Protected
Storage dialog box appears to inform you of the use of your
certificate, users are going to believe that hitting Cancel is
going to cancel their message entirely. If the message composed
was intended to be encrypted, due to its sensitive nature, and
they do hit Cancel, this sensitive information will be sent
encrypted. Further, no other information is provided to the
sender. They are not informed that the message has been sent
anyway unencrypted. If the recipient views the contents by using
the View Message button, they are then able to reply to that
original message. If they do reply, Encryption has been
automatically dropped from the Options, but again, this has been
done without notification to the user. Hence a conversation could
carry on between the two individuals without either of them
realizing that the messages were being sent unencrypted. The
warning dialogs do not explain to the recipient what is wrong with
the message, just that its an invalid signature. Since they can
still see the message (albeit by clicking a few unfamiliar
buttons), they may obviously believe everything is proceeding.
SOLUTION
One workaround for this issue is to not set the security level to
Medium or High but to use Low instead. This prevents the dialog
box from appearing at all, so its not possible to mistakenly send
unencrypted messages in the fashion described above.
Unfortunately, this workaround introduces another exploit
possibility. If the setting is set to Low, then a rogue process
could cause a message to be created by your machine and sent,
signed with your certificate, all without you knowing. The
purpose of the Medium setting is to avoid precisely this
possibility. Setting your security level to High is not a
workaround. You will then be presented with numerous dialog
boxes, none of which provide any useful information as to what is
taking place.