102798 - Security issue for simple MAPI

Status: RESOLVED FIXED

(MailNews Core :: Simple MAPI, defect, P1)

Description

[Tiantian Kong]

Tiantian,

As noted on http://support.microsoft.com/support/kb/articles/Q291/3/87.ASP one
of the typical attacks against Outlook / Outlook Express is to use the Simple
MAPI feature to send mail as the user.  All of the recent high profile viruses,
such as Nimda, I Love You, etc., have involved this approach.

The default setting in Outlook Express 6 is to throw a dialog asking the user if
they actually want to send an email whenever another application tries to do this:

"By default, Outlook Express 6 prevents e-mail messages from being sent
programmatically from Outlook Express without your knowledge by displaying a
dialog that enables you to send or not send the message."

I wanted to confirm that, if our Simple MAPI implementation allows other apps to
send email, we have a similar notification mechanism to ensure that users are
aware when it is happening.

Please let me know if we have this safety feature.  If we do not, are we exposed
to this kind of attack?

Thanks,

Dave.

-- 
Dave Barrowman
[e-mail]


============================

Hi, Dave:

Thanks so much for sharing this information with our team.

We'll deal with this issue at the 2nd stage of the simple MAPI project.

Comment 1

[Christopher Hoess (gone)]

cc'ing mstoltz.

Comment 2

[Mitchell Stoltz (not reading bugmail)]

Let's address this problem *before* we ship a browser with MAPI support.
Otherwise we could be open to some of the same attacks as Outlook was, and
there's no excuse for that.

Comment 3

[Mitchell Stoltz (not reading bugmail)]

nsbranch

Comment 4

[Mitchell Stoltz (not reading bugmail)]

After speaking to Dave Barrowman, and considering our time constraints, I think
we can live without this on the branch. We have other protection mechanisms
which should prevent viruses from easily taking advantage of MAPI, and anyway a
virus doesn't *need* MAPI to send mail. Please leave this bug open and add a
warning dialog on the Mozilla trunk when you have time. You can disregard my
earlier comment.

Comment 5

[Mitchell Stoltz (not reading bugmail)]

Sorry, new game plan. Doug Turner has convinced me that we need a warning dialog
on the branch.

Dave's reasoning why we could get along without the dialog was basically that
since we never, to our knowledge, run any downloaded executables without user
consent, a user cannot catch the Nimda worm, for example, through Mozilla.
However, there are other ways of catching that worm, such as by using IE5.5 or
infection via a network share. In those cases, although Mozilla is not
responsible for infecting the machine, Mozilla is reponsible fro spreading the
infection via MAPI.

As another example, consider someone who installs Netscape/Mozilla, which
registers itself as a MAPI server, and then goes back to using IE (or IE makes
itself the default browser again, as it tends to do, many users won't even
notice). Then, any ActiveX control can send mail in the user's name. I think we
need to address this possibility on the branch.

Comment 6

[Jaime Rodriguez, Jr.]

PDT- per mitch's comments.

Comment 7

[Jussi-Pekka Mantere]

Back on the radar.

Comment 8

[Doug Turner (:dougt)]

Attachment: patch which will display a confirm warning dialog prior to sending mail via mapi

Comment 9

[Doug Turner (:dougt)]

Attachment: xul patch which will expose the "Warn Me..." in the preferences.

Comment 10

[Doug Turner (:dougt)]

The first patch adds a warning confirmation dialog prior to login.  Here are
some issues with it that are trival:

1. preference name is "mapi.warn-before-send" should it be something else?  
2. the text that I am using is:

"""
A third party application is attempting to send mail.
Alert me whenever an application tries to send mail using my profile.
"""
The second patch is optional and since I do not consider myself a xul hacker
probably has problems.  What it does successfully is to provide a way to re-able
the warning dialogs.  It adds a checkbox to the mailnews preferences.

mitch, can you review the first patch?
scott, can you sr the first patch and take a look at the second one?
I will see if I can attach some screenshots.  

Comment 11

[Doug Turner (:dougt)]

Attachment: Confirmation Dialog Jpeg

Comment 12

[Doug Turner (:dougt)]

Attachment: Pref panel Jpeg

Comment 13

[Mitchell Stoltz (not reading bugmail)]

Comment on attachment 52011 [details] [diff] [review]
patch which will display a confirm warning dialog prior to sending mail via mapi

In the firat patch, it looks like the function you added is called IsMapiAllowed(), but the function call you added is called DisplayWarningDialog(). Is this a mistake or am I reading this wrong?

Comment 14

[Scott MacGregor]

weird for some reason i'm cc'ed on the bug but I'm not getting notifications on
comment changes. Mitch, is this related to the new security set up for security
bugs? Doug, sorry I missed your comment asking for review. I'll start looking now.

Comment 15

[Rajiv Dayal]

For the attachment (id=52011) :

We should display this warning only when sending blind send mail. We had a
discussion in PDT yesterday and decided that since the user is displayed the
Compose Window in send with UI the user has to click the Send button in the
Compose Window and thus he/she is aware and responsible for what is done. There
is a function nsMapiHook::BlindSendMail in msgMapiHook.cpp for blind send where
we can put this check.

Also the MAPI app may call Login to do other MAPI operations and may never call
Send (although for this release we have implemented only the send operations) so
it might not be a good idea to display the warning dialog during Login.

Comment 16

[Scott MacGregor]

Comment on attachment 52011 [details] [diff] [review]
patch which will display a confirm warning dialog prior to sending mail via mapi

small nit, can you change 
if (warn == PR_FALSE)
to
if (!warn)

Your patch looks good. I have a policy question though. I think we should only bring up this dialog when a 3rd party app is attempting to do a blind send and not when it's doing a regular send which is going to bring up the compose window.

Comment 17

[Scott MacGregor]

adding Seth to the cc list since he's the mailnews FE owner. He can review the
patch for the warn me dialog in the preferences for ya. 

Comment 18

[Doug Turner (:dougt)]

patch 520118 has a problem - if you play to use it (which your not), grep it for
DisplayWarningDialog and replace it with IsMapiAllowed.  

Comment 19

[Tiantian Kong]

Reply from Michelle about new string.

"Date: Thu, 04 Oct 2001 10:02:41 -0700
   

Hi Tiantian,

Sorry but I have bad news. 

If you add it now it will not be translated. Thus it will appear in english in 
all our localized releases. 

Please don't add any new strings now. 

thanks
Michele"

Comment 20

[Doug Turner (:dougt)]

Attachment: Latest diff - BlindSend warning only.

Comment 21

[(not reading, please use [e-mail] instead)]

r=sspitzer on http://bugzilla.mozilla.org/attachment.cgi?id=52071&action=view

please fix these minor nits:

1) instead of kStringBundleServiceCID, I'd do NS_STRINGBUNDLE_CONTRACTID.
2) can you define the defaults for "mapi.blind-send.warn" and
"mapi.blind-send.enabled" in winpref.js 
(not mailnews.js, since these are windows only prefs)
3) can you get robinf (or someone?) to review the strings you added to
mapi.properties 

Comment 22

[Doug Turner (:dougt)]

1) instead of kStringBundleServiceCID, I'd do NS_STRINGBUNDLE_CONTRACTID.

done.
2) can you define the defaults for "mapi.blind-send.warn" and
"mapi.blind-send.enabled" in winpref.js 
(not mailnews.js, since these are windows only prefs)

why?  I do not see a reason to since their default values are fine here?  Is
this for some kind of about:config thing?

3) can you get robinf (or someone?) to review the strings you added to
mapi.properties 

Sure.

Comment 23

[Michele Carlson]

When will you be landing this on the branch? Can it be done today? Please do it
quickly so we can still try to get the translation done.
thanks

Comment 24

[Tiantian Kong]

Trix:

fyi for your testing.

Here's the behaviour from Doug:


> This is the behavior:
>
> During a silent send, we check to see if the preference 
> "mapi.blind-send.enabled" is true.  By default it is not set, so its 
> value is false.  If the user does enable this preference, a dialog 
> will appear warning the user that an application is sending mail 
> blindly. There is a checkbox in dialog which allows the user to 
> disable this warning from occurring again.

Comment 25

[robinf]

Suggested wording for confirmation dialog:

Dialog Title: Confirm
Dialog Text: Another application is attempting to send mail using your user
profile. Are you sure you want to send mail?

(checkbox) Warn me whenever other applications try to send mail from me.

(OK)  (Cancel)

Comment 26

[Doug Turner (:dougt)]

thanks Robin for the fast response!

Comment 27

[Scott MacGregor]

Comment on attachment 52071 [details] [diff] [review]
Latest diff - BlindSend warning only.

sr=mscott modulo Seth's comments to move the prefs to winpref.js and for Robin's suggested wording change.

Comment 28

[robinf]

Re: the proposed new pref in the mail/news pref panel (pref panel jpeg attached
to this bug)--

The mail/news online help does not currently document this pref. If this bug is
approved for the emojo branch, I would then update the mail online help to
document this windows-only new pref. Michele Carlson will have to make the call
as to whether there's enough time to localize the update to the mai/news online
help.

Comment 29

[Doug Turner (:dougt)]

robin, no worries.  that pref dialog change is not going in.

Comment 30

[Jaime Rodriguez, Jr.]

pls get some testing on this one.

Comment 31

[Jaime Rodriguez, Jr.]

pls check this into the branch, when you think it is ready - PDT+

Comment 32

[Doug Turner (:dougt)]

Attachment: Final Patch. Includes all comments.

Comment 33

[Tiantian Kong]

We'll check in the strings for dialog tonight together with the branch landing 
bug to branch only. Test more about the security patch, and check in the patch 
tomorrow.

Comment 34

[Srilatha Moturi]

Checked in the strings to the MOZILLA_0_9_4_BRANCH

Comment 35

[sol]

I'm using commercial branch 2001-10-05-05, and am finding the experience of
sending a document from PowerPoint via the SMAPI support in our email client a
bit confusing.

I can't tell from the discussion above whether this behavior is being addressed,
or whether it should be the subject of another bug.

The confusion - when viewing a presentation in PowerPoint, I select from the
main menu "File | Send To | Mail Recipient ..."

    Our email client: When our mail client is the default MAPI client, I am next
presented with a dialog that asks "Please enter your username and password." I
find this *very* confusing. What username am I being asked for? I have 5 email
accounts - which username is being asked for? Note that this is not a silent,
programmatic initiation of SMAPI, but rather the result of an explicit request
from me. I guessed correctly, and was then taken to the Mail compose window
where the PowerPoint doc was correctly attached. I hit send - everything worked
as expected.

     Outlook Express: When OE is the default MAPI client, after pressing "File |
Send To | Mail Recipient ..." I am next presented with the email compose window,
to which the PowerPoint doc has been attached. After I hit "Send", I am then
asked for my password - apparently as a security precaution. The fact that the
password dialog comes up *after* I press send seems much more intuitive to me -
I know that the password is associated with the email account I am sending the
message from.

Comment 36

[Rajiv Dayal]

Hi Sol can u put ur suggestion in a different bug, there are similiar remarks
about the password field in the logon dialog. We currently have implemented to
display this dialog as per the MAPI specifications however as per ur suggestion
even Outlook does it differently. Since this bug is for a somewhat different
issue and will be closed soon, it would be a good idea to open another bug since
we should definitly give some thoughts to this alternative.

Comment 37

[Srilatha Moturi]

Fix checked in to the 0.9.4 branch

Comment 38

[Tiantian Kong]

Fixed in 0.9.4 branch

Comment 39

[Trix Supremo]

reopening bug since blind send is scheduled for the next release.

Comment 40

[Bradley Baetz (:bbaetz)]

=======
WARNING
=======

This bug appears to have been removed from the security group as part of a mass
nsbeta1 keyword cleanup change last week. This is probably due to bug 107718,
which is a bugzilla bug, since changing the group doesn't seem likely as part of
this mass change. Readding security group restriction, but if there was still a
security hole in this bug, it better get fixed soon...

This doesn't appear to be the case for any of the two bugs affected, though -
they're both open for better fixes (rather than a fix) on the branch later. The
assignee/qa of this bug should check that, though.

Comment 41

[Daniel Veditz [:dveditz]]

This one may not need to be in the security-sensitive group as the dangerous
code was never on the Mozilla trunk and landed on the branch after the 0.9.4
release.

Comment 42

[Tiantian Kong]

We are in the process of getting more applications that perform silent send. 

Silent send is turned off by default in 0.9.4 branch.

Comment 43

[Ben Bucksch (:BenB)]

Tiantian, this bug is only relevant for the 0.9.4 branch, and there only if
"mapi.blind-send.enabled" is enabled, which is a hidden pref. I.e. there's no
way a user would run into this bug (e.g. after getting Nimba on his machine),
unless he *manually* sets that pref in prefs.js or similar. I.e. no need to
worry about this one yet. Is that correct?

[Slightly OT]
Comment #22 From Doug T:
> > 2) can you define the defaults for "mapi.blind-send.warn" and
> > "mapi.blind-send.enabled" in winpref.js 
[...]
> why?  I do not see a reason to since their default values are fine here?
> Is this for some kind of about:config thing?

It is my understanding that it is a policy that *all* prefs must have an entry
in the default prefs. This might be needed for determining, which prefs the user
sat (i.e. different from default). It certainly is a way to document available
prefs for developers and advanced users.

Comment 44

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 45

[Jeff Hooker]

removed jhooker from cc: list

Comment 46

[Robert Accettura [:raccettura]]

David, now that we have bug 108275.  Is this bug still relevent?

Comment 47

[David :Bienvenu]

it's only an issue if you set the hidden pref that enables blind send in the
first place. It seems that if you set that pref, then you get what you ask for,
but we could consider this patch as an extra level of security, I guess.

Comment 48

[David :Bienvenu]

this has already been checked in...I'm going to change the default for blind
send to true, now that the dialog pops up first.