Security impact by mozilla automatically attempting to download mail parts (attachments)

VERIFIED FIXED in mozilla1.0

Status

--
critical
VERIFIED FIXED
17 years ago
5 years ago

People

(Reporter: david, Assigned: bugzilla)

Tracking

({dataloss})

Trunk
mozilla1.0
x86
All
dataloss
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ADT NEED INFO] DoS, URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

17 years ago
This email when placed in an email spool will cause mozilla to initiate a file
download. The ramifications for this may not be recognized immediate..so, If I
send an email to a victim and I compose it so there are 500 1 byte attachments
like the above form.  Then there will be 500 popups on that user's desktop
asking what to do with that file.

I don't want to see mozilla follow the trend of LookOut Virus Installer (tm).

I am running this on Linux, I imagine the other platforms react similarly.  If
you can reproduce this on another platform, please change the OS field.

(mpt cc: by request of bz)
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is basically a trivial denial-of-service, made slightly worse by the fact
that it can be delivered by a mail message. I'm not sure we need to address this
right now, and I can't think of a good fix.
Assignee: mstoltz → ducarroz
Component: Security: General → MIME
QA Contact: junruh → esther
Whiteboard: DoS
(Reporter)

Comment 2

17 years ago
A couple comments.

a) Should moz be automatically attempting to process email attachments?
b) Are there any methods at this point in time to limit the number of popups?

Comment 3

17 years ago
I think it would be a good thing to limit the number of mozilla generated popup
dialogs to, say, 10 or 20.

Or maybe have just one window/dialog/popup which contains all the messages which
you can scroll through all the messages.

Comment 4

17 years ago
mls: would the download manager alleviate the too many windows problem?
*** Bug 112111 has been marked as a duplicate of this bug. ***
bug 112111 has a good summary of the security problem here (the fact that users
tend to trust files that are on their hard drive)
Summary: Security impact by mozilla automatically attempting to download mail parts → Security impact by mozilla automatically attempting to download mail parts (attachments)
*** Bug 112567 has been marked as a duplicate of this bug. ***

Comment 8

17 years ago
Also, why does Mozilla save the attachment to a local temp file?
OS: Linux → All

Comment 9

17 years ago
see also bug 112562 and bug 55690

Comment 10

17 years ago
*** Bug 113073 has been marked as a duplicate of this bug. ***

Comment 11

17 years ago
Limit to 10-20 popups??? Opening a mail to read it MUST NEVER open a Save As
dialog automatically! Doing that can make users accidentally save the file,
forget about it, find it on their harddisk a month later, wonder what it might
be, and doubleclick it to see what it does. Very bad thing.

(Changing severity to critical since this might cause users to accidentally run
a virus)
Severity: major → critical

Comment 12

17 years ago
Even if we fix this for iframes in the mail window, a mail message could still 
open a browser window using javascript, and have the browser load a page that 
initiates a download.  When bug 49141 and bug 102380 fixed, the result would be 
similar to the one in this bug (a download window would appear when you preview 
a malicious message).  I don't know how to fix that except to disable 
window.open (or all javascript) in mail messages.
(Reporter)

Comment 13

17 years ago
javascript on|off is already a pref, I think the best thing is a default policy
of 'simple rendering' of mail.  generally, don't attempt to do anything but
display the message.  that is to say, in this case, don't automatically try to
download/save an attachment.  in the case of window.open, don't.

naturally we could be user friendly about this and have prefs paranoia option(s)
to complement the current options.

Comment 14

17 years ago
Adding some keywords...
Keywords: 4xp, dataloss, mozilla0.9.9, nsbeta1

Comment 15

17 years ago
Comment on comment 8: On my Win98 system, after downloading the latest update
for the antivirus checker, I always see a warning about BadTrans worm, when I
preview a message containing the worm. Thankfully, my system is not infected
(poor IE users...) but we shouldn't save to $Windows\temp directory. Users might
think Mozilla can be affected from such worms to the same degree as Outlook
does. Worse than that, an uninformed user might (manually) execute the worm,
while browsing the above directory.

Comment 16

17 years ago
I agree with 15. I was very surprised when Mozilla automatically confronted me
with the save dialogue box just by viewing the Badtrans email. Virus writer is
1/4 of the way there if clueless users immediately get presented with this
option. Too many will probably go ahead and do it.
*** Bug 112054 has been marked as a duplicate of this bug. ***

Comment 18

17 years ago
*** Bug 115099 has been marked as a duplicate of this bug. ***

Comment 19

17 years ago
One way to fix this particular bug, while simultaneously exacting revenge on
Windows for their bletcherous practice of using file extensions to record
filetype, would be to say: `Oh, you're "Content-Type: audio/x-wav"? Fine then,
we'll offer to save you as readme.WAV rather than readme.EXE.'

However, that would only neuter BadTrans; it wouldn't solve the general problem,
which I don't think is a MIME problem, nor even a mail/news problem. The essence
of the document is
|
| <iframe src="file-which-Mozilla-doesn't-handle-directly"
| height="0" width="0"></iframe>
|,
and if multiple variations of that element were present in the document it would
be just as much a problem in the browser as it would be in the mailer -- an
indefinite number of `What do you want to do with this luverly file?' alerts.
Timeless is correct that an automatic download manager could solve this problem,
however in Mac IE (which has such a download manager) I still end up with a
bunch of britspears.exe files on my desktop. If I wasn't on a Mac, curiosity
would kill the cat.

In bug 83754, I suggested replacing the alert posed by the default plug-in with
an in-line button, and a clickable message in the status bar saying `[%] Done,
but some objects have no plug-in'. For this bug, I think the same should be done
(a) for IFRAMEs as well as OBJECTs and EMBEDs (which may be true already), and
(b) for files of a type which Mozilla knows it is supposed to save rather than
open. This solution would work for mail/news as well as for Navigator.
(Assignee)

Comment 20

17 years ago
not sure I am the right person for this bug! Anyway, I'll take a look at it soon...
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.8

Comment 21

17 years ago
mstoltz@netscape.com wrote:
> I'm not sure we need to address this right now

Oh. My. God.

Well, Mozilla and Netscape 6 just made it to my list of e-mail clients to not
let any of my friends and family use. What a fucking joke. Although considering
the poor attention to security in navigator I've seen, I don't know why I didn't
assume mailnews was just as bad or worse before running across this bug.

Updated

17 years ago
Blocks: 92997

Comment 22

17 years ago
reassigning to mscott. Is there anything we can do about this in mail?  In the
code that pops up the download dialog can we tell we're in mail and not bring up
the dialog?  Can we put some kind of UI in the message that the user could click
on so that they could bring up the dialog if they wanted to?
Assignee: ducarroz → mscott
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.8 → mozilla0.9.9

Updated

17 years ago
QA Contact: esther → trix

Comment 23

17 years ago
*** Bug 121371 has been marked as a duplicate of this bug. ***

Comment 24

17 years ago
Exactly why should anything be allowed to execute or pop up anything 
automatically while reading mail?  In the broader context of security issues, 
I can't begin to imagine a legitmate use for it.  Reading E-Mail should be a 
totally passive experience, with nothing being displayed but a message body.

Along these lines, why is Javascript for mail even offered as an option, much 
less the default?  Why would any feature be added to Mail that unrelated to 
sorting, composing, and replying to messages while exposing the user to 
nasties we can only begin to imagine how they might be exploited.  Outlook can 
afford the nickname "Lookout", but Mozilla simply can't.

Strip the darn attachments out of the letters as they come in, save them to 
disk, and let the user's anti-virus deal with them.  Remove all Javascript and 
any other scriptability from the mail clients functionality, as it provides no 
value to legitimate E-Mail.  In short, serious thought needs to be given to 
the whole picture of security involving the mail client.

Updated

17 years ago
Blocks: 54184

Comment 25

17 years ago
Mitch do you still agree with what you wrote in
http://bugzilla.mozilla.org/show_bug.cgi?id=109249#c1 on 11/15?  Can we move
this bug past 1.0? 
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.9 → ---

Comment 26

17 years ago
Michael Collette: see bug 65224, "this message opens up a browser window (from
mozilla and 4.x)" [when javascript is enabled in mail].

Comment 27

17 years ago
Discussed in 2/27/02 Mail & News bug meeting.  Decisions was to plus this bug.
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla1.0

Comment 28

17 years ago
reassigning to ducarroz
Assignee: mscott → ducarroz
Status: ASSIGNED → NEW

Comment 29

17 years ago
ADT Needs info: Mitch, you still believe the original assessment
Whiteboard: DoS → [ADT NEED INFO] DoS
(Assignee)

Comment 30

17 years ago
fix for bug 30888 give a good alternative to this bug by giving the choose to
the user to either sanitize HTML or convert HTML to plain text in received message.
(Assignee)

Comment 31

17 years ago
Here is my solution to this problem:

I will not link to the message body releated parts that are not displayable
inline. Instead, I'll show them as attachment. That fix will also show any
non-linked related part as attachment instead of just loosing them.
 
Status: NEW → ASSIGNED
Whiteboard: [ADT NEED INFO] DoS → [ADT NEED INFO] DoS, Have fix
(Assignee)

Comment 32

17 years ago
Created attachment 75471 [details] [diff] [review]
Proposed fix, v1

mimei.cpp & mimeobj.h:
I have recycled an unused member variable of MimeObject that I have called
dontShowAsAttachment. That will let we mark any related part that we link to
the message body as not to be shown as attachment.

mimemoz2.cpp:
I have modified the function that build the attachment list to first accept to
process multipart/related parts and second to respect the new attribute
dontShowAsAttachment.

mimemrel.cpp:
I have created a class to hold a MimeObject pointer and a URL. I used that as
the hash table value instead of using onlythe url as the value for the hash
table.

When we are done parsing a related object (part), I check if we are able to
display it inline before accepting to add it's url into the hash table.

When we are emitting the body part, once I have found the url of an object we
have to link to, I mark the object as not to be displayed as attachment.

Comment 33

17 years ago
So HTML mail will still be able to display images and load documents into
IFRAMEs, it will just ignore unsupported embedded content e.g. executables?
This looks like a great solution to me.
(Assignee)

Comment 35

17 years ago
Be aware that will block only links to a related part. If the iframe contains a
link to a remote source, it will not block it:

<iframe src=cid:{suspicious part}> will be inative but
<iframe src=http://....> will stay active

And to answer neil question, yes embedded image and text/... docs will be
displayed inline.

Comment 36

17 years ago
Comment on attachment 75471 [details] [diff] [review]
Proposed fix, v1

r=cavin.
Attachment #75471 - Flags: review+

Comment 37

17 years ago
*** Bug 133151 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

17 years ago
Blocks: 76323

Comment 38

17 years ago
Comment on attachment 75471 [details] [diff] [review]
Proposed fix, v1

So what's up with storing a const char string m_url and then trying to free it
in the destructor:

+    if (m_url)
+      PR_Free((void *)m_url);

That looks pretty weird.
(Assignee)

Comment 39

17 years ago
Created attachment 76084 [details] [diff] [review]
Proposed fix, v2

I have addressed mscott's comment. Also, the hashtable value will hold it's own
copy of the url to simplify the ownership of it.
Attachment #75471 - Attachment is obsolete: true

Comment 40

17 years ago
Comment on attachment 76084 [details] [diff] [review]
Proposed fix, v2

r=cavin.
Attachment #76084 - Flags: review+

Comment 41

17 years ago
Comment on attachment 76084 [details] [diff] [review]
Proposed fix, v2

it looks like we are only caching the mime object so we can get at the boolean
for showing as attachment. Can we just cache the boolean and a string in your
class instead of the whole mime obj? That reduces the risk of dereferencing a
null mime object that went away on us.
(Assignee)

Comment 42

17 years ago
I need to write in the boolean! Would you me to store the address of the boolean
rather that the address of the mime object?

The mime object is not going away until we are fully done with the stream
conversion, else we would have been crashing all the time, even without that patch.

Comment 43

17 years ago
Comment on attachment 76084 [details] [diff] [review]
Proposed fix, v2

oops i didn't notice you writing to it. Thought you were just reading it. 

sr=mscott
Attachment #76084 - Flags: superreview+

Comment 44

17 years ago
Comment on attachment 76084 [details] [diff] [review]
Proposed fix, v2

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #76084 - Flags: approval+
(Assignee)

Comment 45

17 years ago
Fix checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Whiteboard: [ADT NEED INFO] DoS, Have fix → [ADT NEED INFO] DoS

Comment 46

17 years ago
I just received a virus and nothing happened. That was the idea, right? :-)
Status: RESOLVED → VERIFIED

Comment 47

17 years ago
it was a particular type of message that was causing the problem. I attached
that message to bug 133151

Comment 48

17 years ago
heh. your message looked just like the virus that didn't give me a problem,
but trying to display your message in the browser triggerd a virus alert!
So the problem is only fixed for the message window, when all messages
automatically load into message windows that will solve that version as well.
*** Bug 122790 has been marked as a duplicate of this bug. ***

Updated

17 years ago
No longer blocks: 54184

Comment 50

14 years ago
Just to make sure: the eMail referenced in the URL part:
http://stuph.org/broken-autodownload.eml
is recognized as containing a virus by my AV software when I try to save it.
It's the "AntiVir Guard for Windows XP", and it says
"Enthält Signatur des Windows-Virus W32/Nimda.eml"

Is it correct that your sample message contains the W32/Nimda virus (in which
case I would suggest to remove it), or is the AV software in err ? 
Any comment greatly appreciated !

Comment 51

14 years ago
Just to make sure: the eMail referenced in the URL part:
http://stuph.org/broken-autodownload.eml
is recognized as containing a virus by my AV software when I try to save it.
It's the "AntiVir Guard for Windows XP", and it says
"Enthält Signatur des Windows-Virus W32/Nimda.eml"

Is it correct that your sample message contains the W32/Nimda virus (in which
case I would suggest to remove it), or is the AV software in err ? 
Any comment greatly appreciated !
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.