Closed Bug 109249 Opened 23 years ago Closed 22 years ago

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

Categories

(MailNews Core :: MIME, defect)

Product:
MailNews Core
Component:
MIME
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: david, Assigned: bugzilla)

References

(
URL
)

Details

(Keywords: dataloss, Whiteboard: [ADT NEED INFO] DoS)

Attachments

(1 file, 1 obsolete file)

Proposed fix, v2
7.06 KB, patch
cavin
: review+
mscott
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
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
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?

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.
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. ***
Also, why does Mozilla save the attachment to a local temp file?
OS: Linux → All
see also bug 112562 and bug 55690

*** Bug 113073 has been marked as a duplicate of this bug. ***
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
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.
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.

Adding some keywords...
Keywords: 4xp, dataloss, mozilla0.9.9, nsbeta1
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.
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. ***
*** Bug 115099 has been marked as a duplicate of this bug. ***
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.
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
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.
Blocks: advocacybugs
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
QA Contact: esther → trix
*** Bug 121371 has been marked as a duplicate of this bug. ***
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.
Blocks: Beonex
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 → ---
Michael Collette: see bug 65224, "this message opens up a browser window (from
mozilla and 4.x)" [when javascript is enabled in mail].
Discussed in 2/27/02 Mail & News bug meeting.  Decisions was to plus this bug.
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla1.0
reassigning to ducarroz
Assignee: mscott → ducarroz
Status: ASSIGNED → NEW
ADT Needs info: Mitch, you still believe the original assessment
Whiteboard: DoS → [ADT NEED INFO] DoS
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.
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
Attached patch Proposed fix, v1 (obsolete) — — Splinter Review 
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.
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.
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 on attachment 75471 [details] [diff] [review]
Proposed fix, v1

r=cavin.
Attachment #75471 - Flags: review+
*** Bug 133151 has been marked as a duplicate of this bug. ***
Blocks: 76323
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.
Attached patch Proposed fix, v2 — — Splinter Review 
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 on attachment 76084 [details] [diff] [review]
Proposed fix, v2

r=cavin.
Attachment #76084 - Flags: review+
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.
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 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 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+
Fix checked in
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Whiteboard: [ADT NEED INFO] DoS, Have fix → [ADT NEED INFO] DoS
I just received a virus and nothing happened. That was the idea, right? :-)
Status: RESOLVED → VERIFIED
it was a particular type of message that was causing the problem. I attached
that message to bug 133151
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. ***
No longer blocks: Beonex
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 !

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.

Attachment

General

Creator:
Created:
Updated:
Size: