191460 - Virusmail executes embedded virus. (netsky.p@MM, W32/KLEZ.H@mm)

Status: RESOLVED FIXED

(MailNews Core :: Attachments, defect)

Description

[tmiksch]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212

A W32/KLEZ.H@mm infected mail seems to be executed when mail gets focus.
After the mail gets the focus the MS-Office 2000 installer starts.
The virus contains a HTML file with an iframe
 <iframe src=3Dcid:H7059f3b1tg494Yn height=3D0 width=3D0>
Content-Type: audio/x-wav; name=class.bat
and the virus code.
Selecting the "View->Message Body As->Plain Text / Simple HTML" option prevents
the execution.

Reproducible: Always

Steps to Reproduce:
1. Originating HTML as Viewmode selected
2. The W32/KLEZ.H@mm Virusmail gets focus
Actual Results:  
MS-Office Premium 2000 installer starts

Expected Results:  
Not to execute anything at all :) Or for what reason did I switch from OutlookEx
to Mozilla ?

A very supportive Mozilla developer member suggested that the content-type
audio/x-wav has the WMP (windows media player) as MIME type and the virus 
used a security bug in this software to execute.
WMP Version: 7.00.00.1956
However I don't understand why MS Office Premium 2000 installer starts.

Comment 1

[Matthias Versen [:Matti]]

You should also disable Javascript for Mailnews and also disable plugins for
mailnews

Comment 2

[Boris Zbarsky [:bzbarsky]]

We have code in helper apps to prevent us from launching that content as a .bat
file.  However, if the helper you have configured is a security hole, there is
not much we can do about that (short of blacklisting helpers; perhaps not even
then).  You should revert the settings change you made to launch WMP without
prompting.

Comment 3

[tmiksch]

I checked additional information and I must add the following:
Browsing on a page with a .wav file on it causes Mozilla to ASK me whether to
play it. Also it wants to play it with Winamp 3.0 not with WMP.
about:plugins shows me that the WMP plugin is not linked with .wav as MIME type.

Comment 4

[Ben Bucksch (:BenB)]

tmiksch, as I told you, the .wav extension (.wav is not a mimetype) is
irrelevant here. What matters is the "audio/x-wav" mimetype.

Comment 5

[Boris Zbarsky [:bzbarsky]]

[e-mail], what does clicking on this link do?

data:audio/x-wav,Not_a_Real_wav

Comment 6

[tmiksch]

OK :)
the MIME type x-wav is linked with wmplayer.
Sry for the misinformation, I was wondered about winamp to start up for a wav.
And for the mail above me, the link causes mozilla to ask me whether to
launch winamp. 

Comment 7

[Mitchell Stoltz (not reading bugmail)]

[e-mail], just to confirm, did you have Mozilla configured to launch
x-wav files without user confirmation?

Comment 8

[tmiksch]

Where may i check this ? 
As far as plugins and scripts for mail are concerned, I had it deactivated.
I' ve only Javascript for webpages activated. 
But I must admit that i am not 100% sure because after the "accident" I tried a
lot of options.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Preferences > Navigator > Helper Applications.  Find the audio/x-wav setting and
check whether the checkbox to "Always ask" is checked in the dialog you get when
you "Edit" it.

Comment 10

[tmiksch]

In my version of Mozilla the File Type Listbox is empty.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Oh, right.  You have an old build...

Look in prefs.js.  There are two sets of "neverAsk" prefs (just search for that
string).  You're interested in the ones that are "neverAsk" for opening.

Comment 12

[tmiksch]

No "neverask" || "ask" in any prefs.js

Comment 13

[Boris Zbarsky [:bzbarsky]]

Could you possibly attach your prefs.js file (the one for the profile we're
talking about here)?

Comment 14

[Boris Zbarsky [:bzbarsky]]

And just to make sure, the link in comment 5 is still launching mplayer without
asking?

Comment 15

[tmiksch]

The time comment #5 was written Winamp Version 3.0 started.
Meanwhile I installed Quicktime which now starts when clicking pn this link.
BUT mozilla asks me whether to launch quicktime (for winamp3.0 the same)

 

Comment 16

[tmiksch]

A suggestion:
Why not test whether MIME Type and file extension do match?
A virus like W32 wouldn't have the possibility to exploit this bug in WMP.

Comment 17

[Boris Zbarsky [:bzbarsky]]

> Why not test whether MIME Type and file extension do match?

Because they often do not in quite legitimate content (especially with web
content, where the extension often corresponds to a server script).

That said, on Windows we force the extension and type to match before launching
the helper (by changing the extension).  That way the helper can't be fooled
into thinking the data is an exe and launch it.

Comment 18

[Markus Merz]

Just to confirm most of the above also for netsky.p

1. The following code in HTML view activated the virus after clicking the link:
2. What I did (see below)

The message:

<BODY bgColor=3D#ffffff>If the message will not displayed automatically,<br>
follow the link to read the delivered message.<br><br>
Received message is available at:<br>

<a href=3Dcid:031401Mfdab4$3f3dL780$73387018@57W81fa70Re height=3D0
width=3D0>www.xxx.de./inbox/order/read.php?sessionid-14501</a>
<iframe
src=3Dcid:031401Mfdab4$3f3dL780$73387018@57W81fa70Re height=3D0 width=3D0></iframe>
<DIV>&nbsp;</DIV></BODY>

The critical code:

<iframe
src=3Dcid:031401Mfdab4$3f3dL780$73387018@57W81fa70Re height=3D0 width=3D0></iframe> 

The content as audio/x-wav containig the virusfile message.scr:

------=_NextPart_000_001B_01C0CA80.6B015D10
Content-Type: audio/x-wav;
    name="message.scr"
Content-Transfer-Encoding: base64
Content-ID:<031401Mfdab4$3f3dL780$73387018@57W81fa70Re>

2. What I did

1. (optional / maybe stupid) appplication/scr as helper application. This step
is kind of stupid because this is not the Content-Type. But maybe in the future.
2. Deactivated Plugins for Mail and Newsgroups
3. Deactivated Javascript for Mail and Newsgroups
4. Created helper application for Content-Type audio/x-wav with settings "save
it to disc" + "always ask me before handling this type of files".

Step 4 has to be repeated for every 'new' Virus-Content-Type :-(

Markus

Comment 19

[Markus Merz]

It doesn't help. All four steps from #18 did not help.
I testeded a new virus mail with McAffee OFF.
Click on link in HTML-mail: File is saved and executed.
-> Always have your virus scanner ON
-> If in doubt, check mail in plain text mode:

menue: view / message body as / plain text

Markus

Comment 20

[Markus Merz]

In regard to the massive spread of worm or virus mails
- I recommend to change severity to major or higher
- I recommend a change of the summary to "Virusmail  executes embedded virus?
(netsky.p@MM, W32/KLEZ.H@mm)"
- I recommend the keywords mailtrack and nsenterprise
   - mailtrack -> I recommend a change to product mail/news
   - nsenterprise -> As mail admin I would see this bug as a 'killer' argument
against the use of Mozilla. To be secure a 3d Party product must be used.
- I could confirm #18 an #19 twice with netsky.p
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040316

Markus

Comment 21

[Christian Eyrich]

After some testing with a harmless app as "virus". I didn't manage to execute
the virus with the original Content-Type 1. without request 2. automatically.
Maybe it works with audio/x-wav in some other environment (e.g. plugin installed).

But changing Content-Type to image/png made Mozilla at least pop up the dialogue
 without user interaction when opening the message (or preview pane).

And with the "right" entry in Helper Applications (Mime Type
application/octet-stream or any MIME Type and Extension scr - both with "Always
ask" unchecked), even without dialogue.

The "right" Mime Type entry is sufficient for execution on click to a href.

Comment 22

[Christian Eyrich]

Attachment: the mail with harmless app as virus

Full working mail (body from Markus) for illustration (didn't have hello world
at my fingertips).

Comment 23

[Boris Zbarsky [:bzbarsky]]

Could someone break down comment 18 through comment 22 into a simple
step-by-step  "here is how you reproduce it" thing?  What exact MIME settings
have to be used to get the app in that last mail to execute, for example?

Should the "scr" extension simply be tagged as "executable" by Mozilla?  Right
now it is not.

Comment 24

[Markus Merz]

(In reply to comment #23)
about: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040316

Step-by-Step:
I am getting a HTML mail containig an invisible file message.scr (see sourcecode
below). The attachment can only be seen in pure text mode. In HTML mode you only
see the link text with a very small point after the link.
The file message.scr is hidden behind a nonsense link which really points to 
an iframe tag (see sourcecode below).

The link which is shown in the status line is:
mailbox:///E|/Daten/mozilla.mail/Profiles/default/unpq7tln.slt/Mail/Local%20Folders/Junk?number=55643&part=1.2&filename=message.scr

McAffe is OFF:
I click on the link and the virus is executed.

McAffe is ON:
I click on the link and Mozilla is trying to save the decoded file automatically
in temp. McAffee is giving me the info 'file access refused' i.e. for
C:\TMP_OS\12kzgug5.scr (the name varies). So this step is interrupted by
McAffee. (If I save the base 64 encoded message.scr as message.scr McAffee does
not recognise the virus pattern.)

Short after the interuption Mozilla pops up (1) the saving dialogue followed by
(2) an error box titled 'opening message.scr'. The saving dialogue can not be
activated. The error box tells me:
"C:\TMP_OS\message.scr could not be saved, because you cannot change the content
of that folder.
Change the folder properties and try again, or try saving in a different location."
After OK both boxes disappear and nothing else happens.

> Should the "scr" extension simply be tagged as "executable" by Mozilla?  Right
> now it is not.

I do not understand " "executable" by Mozilla "?

I think to be on the save side all executable Windows extensions should be
handled by Mozilla in a 'save' way by default. (application/pif,
application/exe, application/scr, application/com, ...)

In #18 I did not add the extension scr! If I add application/scr and extension
scr to this helper application then Mozilla asks me what I want to do.

In Windows OS the file extension .scr means screensaver and is executable by the
OS. The fun with this bug would be gone if I tell the OS or Mozilla to open .scr
files in an editor (If Win accepts it?).

But the real bug is not the extension. Executable extensions are a Windows
problem, not a Mozilla problem.
I think the Mozilla bug is the execution of the iframe and the hiding of the
attachement.
<iframe
src=3Dcid:031401Mfdab4$3f3dL780$73387018@57W81fa70Re height=3D0 width=3D0></iframe>

The last mail / nearly the whole sourcecode:

Subject: Mail Delivery (failure [e-mail])
Date: Mon, 29 Mar 2004 09:05:03 +0200
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_000_001B_01C0CA80.6B015D10"
X-Priority: 3
X-MSMail-Priority: Normal
Message-Id: <[e-mail]>

This is a multi-part message in MIME format.

------=_NextPart_000_001B_01C0CA80.6B015D10
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_001C_01C0CA80.6B015D10"

------=_NextPart_001_001C_01C0CA80.6B015D10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_001_001C_01C0CA80.6B015D10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>If the message will not displayed automatically,<br>
follow the link to read the delivered message.<br><br>
Received message is available at:<br>

<a href=3Dcid:031401Mfdab4$3f3dL780$73387018@57W81fa70Re height=3D0
width=3D0>www.xxxxx.de/inbox/order/read.php?sessionid-3042</a>
<iframe
src=3Dcid:031401Mfdab4$3f3dL780$73387018@57W81fa70Re height=3D0 width=3D0></iframe> 
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_001_001C_01C0CA80.6B015D10--

------=_NextPart_000_001B_01C0CA80.6B015D10
Content-Type: audio/x-wav;
	name="message.scr"
Content-Transfer-Encoding: base64
Content-ID:<031401Mfdab4$3f3dL780$73387018@57W81fa70Re>

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAYAAAAA4fug4AtAnNIbgBTM0hV2luZG93cyBQcm9ncmFtDQokUEUAAEwBAwAAAAAA
[...]
TGG8RXLcXOvFjE11CHjMTgMAAAAAAAAAAAAAAAAA

------=_NextPart_000_001B_01C0CA80.6B015D10--

I hope I could help.

If you can follow my arguments please set this bug to a higher level as I
mentioned in #20.

Markus

Comment 25

[Christian Eyrich]

Markus, the visible link doesn't point to the iframe. The iframe's src and the a
href point to the same resource: the attachments cid.
Both have the same aim, to execute the attachment, either automatically or manually.

Boris, what I wanted to say in comment #21. I don't get the virus/attachment
executed without Mozillas "opening message.scr" dialogue popping up.
To not getting asked, a Helper Application has to be defined with either
1. Mime Type application/octet-stream (no Extension needed)
or
2. any MIME Type (like blabla) and Extension scr
but with "Always ask" unchecked in any case.

With Content-Type: audio/x-wav; the iframe does nothing. To execute the
attachment, one has to click on the a href link.
But with Content-Type: image/png; the attachment gets executed when opening the
mail is renderd in the preview pane or an own window.
With or without Mozillas dialogue depends on the Helper Application.

So step by step to execute the "virus" with my attached mail:
* Open it
To get it executed without dialogue:
* Add a new Type in Helper Applications,
   MIME Type: Blabla
   Extension: scr
   choose "Open it using the default application"
   uncheck "Always ask me ..."
* Open the mail


I'm aware that (in my scenario) the user has to make the failure and advice
Mozilla to open binaries without request.
But I think
1. Mozilla should prevent the automatic execution of any type it can't handle
itself. This type shouldn't be determined by looking at the Content-Type (as
this is image/png) but the real (guessed) type as displayed in the "opening
message.scr" dialogue (which is application/octet-stream in this case).
2. Mozilla should force the "opening ..." dialogue for all external types when
accessed through a link to the cid (instead on the attachments listbox with
right click "open")

Comment 26

[Frank Wein [:mcsmurf]]

Ok, here is a summery of this bug, since there were some wrong comments here:
With no MIME-Types registered in helper applications the following happens with
a current Mozilla build when viewing the mail.
With Orginal HTML view a dialog opens which asks me what i want to do with the
file "Mail" of type application/octet-stream (open it/open it with/save it),
when clicking the link the same dialog appears.
With Simple HTML view nothing happens, when clicking the link the dialog from
above appears.
With Plain text you only see the text "message.scr"

Comment 27

[Christian Eyrich]

You're talking about the original virus mail from Markus, or about my modified
version?
If the first one that would be interesting as nothing happens here if I just
view the mail. Is something in your Mozilla that tries to handle audio/x-wav?
Maybe the Mediaplayer plugin or something like that?

Comment 28

[Boris Zbarsky [:bzbarsky]]

(In reply to comment #24)
> I do not understand " "executable" by Mozilla "?

No, by the OS.  Perhaps "dangerous" is a better term from Mozilla's standpoint.

> I think the Mozilla bug is the execution of the iframe and the hiding of the
> attachement.

No, that behavior is in fact correct and required by the MIME specs.  Consider
the case when that data really is an image.

> If you can follow my arguments

Not well, since you did not mention what your MIME settings are....

In any case, as far as I can tell from all this mess there are two bugs here:

1)  .scr is not an extension we treat as dangerous.  That needs to change.
2)  We're detecting the type of that attachment based on extension instead of
    based on the Content-Type line.  Why?

I'll attach a patch for issue #1, but issue #2 is a pure mailnews issue.  I'm
not sure why this bug is even in the browser product.

Comment 29

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch for issue 1.

Comment 30

[Boris Zbarsky [:bzbarsky]]

mscott, biesi, do you know why the type is getting reported as
application/octet-stream here?

Comment 31

[Frank Wein [:mcsmurf]]

(In reply to comment #27)
> You're talking about the original virus mail from Markus, or about my modified
> version?

About the attachment on this bug
http://bugzilla.mozilla.org/attachment.cgi?id=144854&action=view

Comment 32

[Christian Eyrich]

Ah, ok, that's comprehensible.

Comment 33

[Markus Merz]

Beside this bug / From the (windows) user point of view I see some points to
mention:

a) browser.helperApps.alwaysAsk.force
browser.helperApps.alwaysAsk.force is false by default
Would true be more safe?
A better default?

New?:
browser.helperApps.alwaysAsk.force.extensions

b) mime type like */*
Can I specify a working mime type like */* where I can list all the dangerous
extensions in >=1.7b ?

c)GUI for dangerous extensions
Does it make sense to have an extended GUI for helper apps where I can list all
the dangerous extensions, which will override the mime settings?
I looked for such a list in about:config but couldn't find such a possibility.

This also makes sense if a mail with such extensions is forwarded. 
sense = Do you really want to forward file X?

d) extension list
McAffee offers a logfile called VSHLog.txt where all the actual extensions can
be listed which they think are dangerous. This would be easy to use. FYI:

szDefaultProgramExtensions=(Keine Erweiterung) ??_ {?? 001 002 386 3GR ACM ADT
AP? ASD ASP AX? BAT BIN BO? CC? CDR CHM CLA CMD CNV CO? CP? CSC D?B DAT DEV DIF
DL? DO? DRV EE? EML EX? FMT FO? GMS GZ? HDI HLP HT? IM? IN? JS? LIB MB? MD? MHT
MOD MPD MPP MPT MRC MS? NWS OB? OC? OL? OLE OTM OV?
 PCI PD? PHP PIF PLG POT PP? PRC QLB QPW QTC REG RTF SCR SH? SIS SMM SYS TD0 TGZ
TLB TSP VB? VS? VWP VXD WBK WIZ WP? WRI WS? X32 XL? XML XSL XTP XX? ZL?

If such an extension is an inline content it is a MUST to warn the user.

e) show attachments in mail and list
I really recommend to show attachments which are executable or marked executable
in the mailbox overview and in the message itself.
I became engaged in this bug by clicking on that link which I would never have
done with a visible attachment with an executable extension.

Markus

Christian: Did you get my virusmail to your GMX account?

Comment 34

[Markus Merz]

(In reply to comment #22)
> Created an attachment (id=144854)
> the mail with harmless app as virus
> 
> Full working mail (body from Markus) for illustration (didn't have hello world
> at my fingertips).

Just to confirm. It works. I am asked which application should open 'Mail'.

Markus

Comment 35

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 145018 [details] [diff] [review]
Patch for issue 1.

scr should absolutely be included here. a screensaver on windows is a normal
executable

I'm amazed that we end with octet-stream here. maybe some bug in exthandler,
when there are user mime settings for octet-stream listing scr as an extension?
hard to tell without a log

Comment 36

[Christian Eyrich]

Christian, I get "The file 'message.scr' is of type application/octet-stream
(Bildschirmschoner)" also when there is no Mozilla MIME setting for either
application/octet-stream or .scr.
"Bildschirmschoner" is taken from the global Windows "Registrierte Dateitypen".
But if removed there, a/o-s is still true.

Comment 37

[Boris Zbarsky [:bzbarsky]]

Attachment: Log

It looks like someone in mailnews is getting the type based on the
extension.... see beginning of the log.

Comment 38

[Boris Zbarsky [:bzbarsky]]

(In reply to comment #33)
> browser.helperApps.alwaysAsk.force is false by default
> Would true be more safe?

True would mean you could never set any type to not ask.  The prefs UI is the
only thing that looks at this pref.  Frankly, I wonder why we have it.  We
should probably remove it.

> browser.helperApps.alwaysAsk.force.extensions

I don't believe this is acceptable (certainly not on non-Windows platforms)

> b) mime type like */*
> Can I specify a working mime type like */* where I can list all the dangerous
> extensions in >=1.7b ?

File rfes.

> c)GUI for dangerous extensions

File rfes.

> d) extension list

File a separate bug on extending this list, please.

> e) show attachments in mail and list

File rfe.

Please keep in mind -- one bug per problem.

Comment 39

[Boris Zbarsky [:bzbarsky]]

Holy smokes.  MIME type determination for mailnews attachments in this scenario
has been completely busted since October 1999, when alecf's checkin to "exorcise
net.h from compose and mime" ifdefed out some rather relevant code (revision
1.14 of mimei.cpp).  See
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/mailnews/mime/src/mimei.cpp&rev=1.66&mark=776-778,788-793#770
and note that |reverse_lookup| is true in that code by default (since the pref
is set to true).  alecf's checkin removed the "and it's not in our table" part
of that check, which makes that code always ignore the Content-Type header for
that part of the message and use the filename instead.

I think the reverse_lookup code and its associated pref should just be removed,
myself.... it's a security hole in general, imo, to detect types based on
extensions in the presence of content-type headers.

Comment 40

[Markus Merz]

(In reply to comment #38)
> (In reply to comment #33)
[...]
> > d) extension list 
> File a separate bug on extending this list, please.

I did. Please see:
http://bugzilla.mozilla.org/show_bug.cgi?id=239160

Thanks Markus

Comment 41

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 145018 [details] [diff] [review]
Patch for issue 1.

Could this be approved for 1.7?  It closes up a security hole viruses can use
to try and auto-execute.

Comment 42

[chris hofmann]

Comment on attachment 145018 [details] [diff] [review]
Patch for issue 1.

a=chofmann for 1.7

Comment 43

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 145018 [details] [diff] [review]
Patch for issue 1.

Checked in the .scr change for 1.7.  Can I get some feedback from mailnews
folks on the other issue?

Comment 44

[Manuel Reimer]

I've tried to reproduce this with the (hopefully) harmless Version of Christian
Eyrich. I've downloaded the ".eml" first. Then I tried to open it with the
file:-Protocol. This try always crashed mozilla after producing 100% CPU Usage
for about 20 seconds. After that I imported this eml file into one of my mbox
files and tried to view the mail. With my Mozilla I only get dialog which asks
me which application should open "Mail". It *doesn't* auto execute for me. Am I
doing anything wrong.

I got the same effect while surfing today. Try this URL (please visit it before
the webmasters change the site). Mozilla asks me which application should open
an "plugin.exe" file. This *also* works if JS is deactivated!!!

And please don't execute the plugin.exe. This may be a virus!!!

DANGEROUS URL!!!
http://www.free-picture.li/cd-cover-free-download.html

Comment 45

[Christian Eyrich]

Manuel, I always wrote that it only auto executes (for me) if you've a MIME
entry for it.

I can't reproduce the automatic execution anymore when having a MIME entry and
open the file attached to this bug. Like you I get the dialog that asks which
application should open "Mail" - but it's from Windows, not from Mozilla.

For mail I wasn't asked anything (with appropriate MIME entry). But the checkin
of attachment 145018 [details] [diff] [review] did a good job, now Mozilla asks where "message.scr" should
be saved.

Comment 46

[Jeremy Hannon]

Where in the code is the list of "executable" or "dangerous" attachments for
windows platform.  In corporate setups, I always block these extensions:

.bat .cmd .com .exe .pif .scr .vb .vbs. .vbe .js .jse .wsh .wsf .wse .lnk .dll
.ocx .msc

I believe that all of theses should be marked as "executable" or "dangerous" if
they are not already.  I know outlook additionally blocks .url, and I usually
block that as well.

Comment 47

[Boris Zbarsky [:bzbarsky]]

If you look at the patch, it's pretty obvious where the list is....  In any
case, further discussion of the list should go to bug 239160.  This bug is about
the broken MIME stuff in Mailnews.

Comment 48

[Mathias Bauer]

After reading through all this, IMHO the main problem is the ignored content
type (the bug that was already discovered by Boris ("holy smokes"). 

Mozilla should always respect the content type and if if finds an associated
helper application or plugin (or if it can handle the type itself), the content
should be handled by the found handler. If (as in the virus) the real file turns
out to be not what it was declared to be, the file can't be displayed
successfully, but OTOH doesn't do any harm.

Besides that I think the current way Mozilla reacts to clicking on links or
opening attachments is basically right: if there is no helper application, the
user should be prompted to decide how to proceed.

But the second step IMHO is wrong: Mozilla should never pass any
attachment/downloaded linked file to the operating system if it can't find a
handler for the declared content type. Only selected helper applications should
be allowed to use, so that executable content will never get executed.

As a compromise, an extension list like the one suggested by Markus could be
used and only files with extensions not in the list are allowed to be passed to
the operating system to let it choose the assigned application automatically. 

Such an extension list should be configurable at least via prefs, so if somebody
discovers a new "bad" extension the security hole can be closed without a new
release.

IMHO the handling of IFRAMES in Mozilla is wrong. If the content type is not
handled by an internal handler (like BMP or JPG) or a plugin, Mozilla should do
nothing, even helper applications shouldn't be called (because they would not be
ablet to display the content inside the frame), but maybe this is only a side
effect of the bug that the content type is ignored.

So I'd like to suggest that the already discovered bug (ignoring content type)
needs to be fixed with a high priority.

I understand that the extension list stuff is discussed elsewhere (239160), but
IMHO without such a list Mozilla should never hand over files to the operating
system.

Comment 49

[Ben Bucksch (:BenB)]

> If (as in the virus) the real file turns out to be not what it was declared
> to be, the file can't be displayed successfully, but OTOH doesn't do any harm.

Actually, that's not true. IIRC, there used to be a bug in Windows Media Player
a few years ago, where an executable fed to the player would be started by the
player. A wurm exploited that hole, by going exactly what we see here: Declare
an exe (with .EXE or similar executable extension) as mimetype associated with
WMP, so the email client would consider it harmless, feed it to WMP, which would
then look at the extension and start the exe.

Comment 50

[Mathias Bauer]

(In reply to comment #49)

> Actually, that's not true. IIRC, there used to be a bug in Windows Media Player
> a few years ago, where an executable fed to the player would be started by the
> player. A wurm exploited that hole, by going exactly what we see here: Declare
> an exe (with .EXE or similar executable extension) as mimetype associated with
> WMP, so the email client would consider it harmless, feed it to WMP, which would
> then look at the extension and start the exe.

That might happen indeed, but that wouldn't be a fault of Mozilla. You can't
solve the security problems of all applications in Mozilla, so maximum security
would mean that Mozilla couldn't use any external application. OK, that would be
possible - but does anybody want that?

Of course you are right that my statement about non-harmful helper apps is not
completely correct - it's only theoretically correct if all used apps are secure
by themselves. But that doesn't change my opinion how it should work. 

BTW: I deinstalled Windows Media Player. :-)

Comment 51

[Ben Bucksch (:BenB)]

Mathias, I think that there'll always be buggy apps (they could even claim "Why
are you feeding me an exe? I assume that the command given to me by another
local app is fine and I'm just doing my best to follow the command", even if the
argument is stupid) and that network apps should act as protective layer between
the evil net and my local system.

bz wrote in comment 28:
> > I think the Mozilla bug is the execution of the iframe and the hiding of the
> > attachement.
> 
> No, that behavior is in fact correct and required by the MIME specs.  Consider
> the case when that data really is an image.

I don't think it makes much sense to auto-execute (iframe, JS etc.) external
helper apps. I don't expect a PDF app to open when I view an email, only when I
explicitly click on a link to a PDF. (And no spec requires us to use any
external apps at all.)

Comment 52

[Markus Merz]

(In reply to comment #51)
> [...] network apps should act as protective layer between
> the evil net and my local system.

That's the point. Mail is a door to the local system. This door should be
handled in a restrictive matter. Never trust the OS :-)

Markus

Comment 53

[Boris Zbarsky [:bzbarsky]]

> I don't think it makes much sense to auto-execute (iframe, JS etc.) external
> helper apps.

<iframe src="realplayer file">

With the assumption that it's played by your plugin.  Except you have no plugin.
 Now does it make sense to use a helper app instead?  Given that there is no
other way for a normal user to get at the content?

Comment 54

[Ben Bucksch (:BenB)]

I would *not* expect to have an external RealPlayer started in that case. Only
by explicit request.

Comment 55

[Boris Zbarsky [:bzbarsky]]

You seem to have different expectations from a lot of users.... (and there is no
good way I see to make said explicit request).  Not to mention that there is no
significant difference between the external app and the plugin here.

Comment 56

[timeless]

bz: personally i'd like to lean towards making plugins click to play, my null
plugin spec does that too. the way to handle this would be to make the iframe
trigger the null plugin and the null plugin would allow click to pass off to a
helper (in addition to allowing the user to save the content to disk or drag it
to some app).

Comment 57

[Joe Sabash [:JoeS1]]

Of course security should be a top priority.
But I think care should be taken to not futher alienate the multimedia user.
There are many users who regularly include javascript animation and
sound files in newsgroup posts and personal email. I think you must depend on
the preference selection of the user to determine what happens 'automatically'
Or perhaps a 'hidden' pref that the 'average user' couldn't unknowingly enable.
If depending on the plugin writer and forcing content to the correct file
extension is not enough, then how about an integrated player that contained all
the precautions you want to build into it.(I'm sure someone could find an open
source candidate)
Mozilla is getting a reputation for being 'multimedia unfriendly'
It would be great to be able to boast that:
"Mozilla does everything I want to do in a convenient and Secure manner"
JoeS

Comment 58

[Boris Zbarsky [:bzbarsky]]

OK.  Could we please take discussion of meta-issues regarding inline content to
somewhere else?  This bug is about a specific MIME issues in mailnews, and the
only comments that should really be happening are answers to the issues raised
in comment 39.

Comment 59

[Mathias Bauer]

(In reply to comment #58)
> OK.  Could we please take discussion of meta-issues regarding inline content to
> somewhere else?  This bug is about a specific MIME issues in mailnews, and the
> only comments that should really be happening are answers to the issues raised
> in comment 39.

I agree that ignoring the content type is the most critical part here. But the
fix for this problem will help only if Mozilla knows to handle the declared
content type. 

What will happen if Mozilla doesn't know to do that? If we would end up in
handing over the content to the operating system it wouldn't be acceptable. 

Even if Mozilla didn't evaluate extensions, the OS does it - and we know what
might happen then. This is not a meta-issue (like discussions about possible
security leaks in other applications or our individual degree of paranoia), this
is a real threat for all non-expert users that think that taking the default
application (as suggested by Mozilla) can't be wrong - they don't know that this
means "let your OS guess how to treat the attachment".

So I still think the current handling of "unknown" content types (means: no
handler of helper app is known) needs to be fixed. I see three possible changes:

- Mozilla doesn't do anything with the content
- Mozilla only hands over content that passes an extension list check
- Mozilla takes the extension and retrieves the necessary helper app for the
file by itself and then explicitly calls it (like an internally configured
helper app); if nothing is found, nothing will be done with the content.

All three way should be able to achieve that no dangerous content is handed over
to the operating system.

Comment 60

[Boris Zbarsky [:bzbarsky]]

> If we would end up in handing over the content to the operating system

When we do that, we ensure the extension matches the content-type, precisely
because the OS is dumb.

For actual "unknown" types as you describe Mozilla always prompts.

Comment 61

[Vaclav Dvorak]

Forgive my ignorance, but is this MailNews-specific at all? It seems to me that
the exact same issue must exist in the browser, and I don't see why the solution
would be any different. Just curious...

Comment 62

[Boris Zbarsky [:bzbarsky]]

The issue THIS bug is about (getting the wrong MIME type) is very specific to
mailnews.

Please take all other discussion to other bugs or to the newsgroups we have for
this purpose.

Seth, Scott, Ducarroz, Bienvenu, any chance of a response?

Comment 63

[Markus Merz]

(In reply to comment #56)
> bz: personally i'd like to lean towards making plugins click to play, my null
> plugin spec does that too. the way to handle this would be to make the iframe

I vote for this null plugin idea. Markus

Comment 64

[Vaclav Dvorak]

(In reply to comment #56)
> bz: personally i'd like to lean towards making plugins click to play, my null
> plugin spec does that too. the way to handle this would be to make the iframe
> trigger the null plugin and the null plugin would allow click to pass off to a
> helper (in addition to allowing the user to save the content to disk or drag it
> to some app).

FWIW, there's a patch in bug 236543 that does almost something like this for the
null plugin (if I understand correctly), or at least it allows saving the
content. And now I'll shut up, and sorry about the spam if you don't find this
relevant.

Comment 65

[Boris Zbarsky [:bzbarsky]]

Since people feel like blabbing about all sorts of irrelevant issues, please
re-cc me once one of the mailnews folks comments on the issue at hand.  If that
ever happens, what with all the irrelevant noise in this bug.

Comment 66

[Manuel Reimer]

I think the feature "use default application" should be removed completely. See
the following comment: http://bugzilla.mozilla.org/show_bug.cgi?id=239160#c7

And of course IFRAMEs don't have to execute external applications! They only
should use plugins!

Comment 67

[David :Bienvenu]

I agree that it's a security hole. Unfortunately, I'm sure that code was there
because mailers weren't setting content types correctly, and they're probably
still out there, along with mail messages sent by them. 

If we wanted to restore it to the way it was before Alec's change, would we use
nsIMIMEService::getFromTypeAndExtension? If so, I'm happy to code that up...

Comment 68

[Boris Zbarsky [:bzbarsky]]

Well...  we _are_ using it already, actually.   That's exactly what this code
does, and that's exactly what's wrong.

As for why the code is there, it looks like a change was started and never
finished.  Or a change was simply screwed up.  I don't care which, really, but
the part of the code that handles misconfigured mailers (when the type is set to
application/octet-stream by the mailer) is already there and is fine, and I'm
not suggesting we remove it.

Again, my suggestion is that we simply remove the (unused) pref and the one
check for it.

Comment 69

[David :Bienvenu]

ok, I'm fine with that. I'll attach a patch, thx.

Comment 70

[Hermann Schwab]

Attachment: popunder

slightly offtopic.
I´ve got the same problem, if I access my mail with the browser via webmail.
Of course I know it´s a virus as I don´t know the sender, and so it must be
spam or a can of worms.
If I use the oldfashioned URL for modem access, I don´t have a problem, If I
use the new URL for access via ISDN or DSL, I´m seeing something flashing
shortly, and then the normal mail, header and body. When I closed mozilla, I
saw the popup, asking me to decide what to do. If I had checked the box 'always
use my decision' maybe I would have been hit by this virus without knowing.

Comment 71

[Boris Zbarsky [:bzbarsky]]

No, because in that case the type we're looking at is audio/wav.  Since .scr is
not a valid extension for that type, we will change the extension on the file
(to a valid extension for that type) before calling the app on it.  Try it, if
you want (with a safer type than .src if desired).

Comment 72

[Markus Merz]

In 1.7rc1 I can't activate the helper applications in the GUI anymore. They are
only listed. No info about the helper applications is shown below the list.

(It is not 1.7b!) - Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b)
Gecko/20040421

Markus

Comment 73

[Markus Merz]

(In reply to comment #72)

Added bug 241307
"GUI Helper Application list is deactivated (1.7rc1 Preferences / 1.7b was OK)"

Markus

Comment 74

[Markus Merz]

quote from bug 239160 comment 26:
> http://bugzilla.mozilla.org/attachment.cgi?id=144854&action=view
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040512
note: bug 239160 comment 20 - In this build .scr should be handled as a harmful
extension by the browser

Just clicking on the link above opens the inline attachment message.scr which is
marked [Content-Type: image/png; name="message.scr"] and after a while W2K asks
me what to do with mail. I am astonished. What is happening here?

Comment 75

[Croco Dil]

on 3 diffrent OS (win XP h&pro, 2k) and three diffrent builds (RC1 and 2 1,8
nightly)
Mozilla asks me what to do with this file he suggests to open it with Irfanview
(my default App. for wav)

Comment 76

[Boris Zbarsky [:bzbarsky]]

Markus, what is going on is that the mail code is still reporting the wrong MIME
type, if nothing else.  I'm not sure what you mean by "opens", and it's
impossible to debug problems remotely unless clear descriptions of what happens
when specific steps are taken are given.

Reassigning to David, since he said he'd work on the MIME type thing.

Comment 77

[Markus Merz]

(In reply to comment #74)
> Just clicking on the link above opens the inline attachment message.scr which is
Now I created a blank new profile, click on that attachment link, Mozilla opens
the page and next Mozilla asks me what I want to do with the file "mail" which
ist content-type octet-stream - "Hmpfff..."
Maybe I should do a brandnew installation with a blank profile and check again.

Comment 78

[Markus Merz]

(In reply to comment #76)
Boris, sorry for my foggy comment(s).

1. I Ctrl-clicked on that link in comment 74. The page loads and the OS asks
which application I want to use für that file "mail". This means the OS opens
that file.
2. Because of comment 77 I change the settings of helper applications
"octet-stream" from "open with default application" to "save to disc" and
"always ask".
3. OK - Now Mozilla asks me what it should do and default is "save to disc".
4. In comment 74  and here in 1 I was astonished because I expected the handling
of .scr to be different now because of the extended extension list patch in bug
239160 comment 20.

Comment 79

[Boris Zbarsky [:bzbarsky]]

> that file "mail"

Is that the actual filename used?  Where does that come from?

Note that if the OS were actually passed a .scr file it would NOT be asking you
anything.

Comment 80

[Markus Merz]

Attachment: comment 78 - screenshot

I don't know where that filename "mail" comes from.

Comment 81

[Boris Zbarsky [:bzbarsky]]

Well, that's not a .scr filename, so filtering out .scr files wouldn't really
affect it, now would it?

I have no idea where it comes from either; that dialog just shows whatever the
channel reported, and the channel is mailnews code.

Comment 82

[Markus Merz]

(In reply to comment #81)
> I have no idea where it comes from either; that dialog just shows whatever the
> channel reported, and the channel is mailnews code.
Just a guess: I am checking it all the time with Christians attachment
http://bugzilla.mozilla.org/attachment.cgi?id=144854&action=view which is Type
message/rfc822 so maybe that's the point where Bugzilla sends the name "mail".

I will send myself such a mail with an inline attachment and see what happens.

Comment 83

[Christian Eyrich]

Just save the attachment and throw it in your mailfolder. After restart you've
the message available.
And indeed, I get "message.scr" as filename when opening it in MailNews, but
"Mail" when opening it in the browser window.

Comment 84

[Markus Merz]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040512

I tried to create a mail with an executable .scr from the local system as inline
content. But I was not able or too stupid or Mozilla couldn't do that or Mozilla
was fixed somehow. Mozilla created the attachment and I manually created the
href and iframe to the cid which I could see in the sourcecode of the draft.
Then I sent me that mail. The inline attached .scr was shown in the attachment
list, the link pointed to a blank page and the iframe did nothing. Maybe my
mistake. Doing a double click on the attachment showed the dialog for "save or
execute with ..." only. The automatic execution is stopped indeed.

So stupid-me decided to send me a link to an excutable on the net.

If I receive the following mail, the download is started automatically and
immediately in the moment when I view the new mail.
Positive: I get the dialog for "save or execute with ..." only. The automatic
execution is stopped indeed.

I stripped down the mail source code to the following by sending me smaller and
smaller mails:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">

<title></title>
The iframe and nothing but the iframe!<br>
<div class="moz-text-html" lang="x-western"><br>
<iframe src="http://keir.net/download/k9v1setup.exe" height="100"
 width="100"></iframe>
<div>&nbsp;</div>
</div>
</body>
</html>

Download starts immediately and automatically when viewing the mail (but is
stopped by the dialogue).

This brings me back to comment 18 where I guessed that the iframe is the source
for the automatic execution of message.scr.

My conclusion: I think that extending the list of possible harmful MS extensions
in bug 239160 solved the auto-execution part of this bug. Maybe not totally - I
did not check it with a .doc document containing macros. I did not have one at
hand on the web or locally.

As many people pointed out before Mozilla should ignore iframe executable
content which it can't handle by itself or by plug-in (remember: disable
plug-ins for mail!). Instead Mozilla should (must?) ignore every other iframe src.

So the handling of iframes should be under review!?

Comment 85

[Boris Zbarsky [:bzbarsky]]

> So the handling of iframes should be under review!?

There are _SEPARATE_ bugs on this.  In fact, in most cases we do want to load
the iframe (say it's just an HTML page).  If you have images disabled, we should
probably not load it.  Also covered by other bugs.

This bug is about the issues in mailnews channels that feed incorrect data to
the necko consumers.

Comment 86

[David :Bienvenu]

Attachment: bzbarsky's proposed fix

Comment 87

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 148447 [details] [diff] [review]
bzbarsky's proposed fix

r=bzbarsky, if you remove that pref from mailnews.js too, as well as fixing the
comments in that file to match the code (more context would have shown the
comments....)

We could probably use a followup bug on the wrong filename issue, btw.

Comment 88

[David :Bienvenu]

resolving fixed - there are other bugs filed on remaining issues, as I
understand it.

Comment 89

[Markus Merz]

(In reply to comment #85)
> This bug is about the issues in mailnews channels that feed incorrect data to
> the necko consumers.

Please see summary: Virusmail executes embedded virus. (netsky.p@MM, W32/KLEZ.H@mm)

Maybe the forks should be
- MIME
- extensions
- iframe

Comment 90

[Markus Merz]

I checked the iframe bugs and found:
bug 213280 - denial-of-service-attack using iframe & telnet-urls
bug 230274 - iframes should be disabled if remote images are blocked
The first one shows clearly the security issue.

Comment 91

[Mike Cowperthwaite]

Comment on attachment 148447 [details] [diff] [review]
bzbarsky's proposed fix

Since this is a security issue, it's probably worth trying to get into 1.7.

Comment 92

[Asa Dotzler [:asa]]

Comment on attachment 148447 [details] [diff] [review]
bzbarsky's proposed fix

a=asa (on behalf of drivers) for checkin to 1.7

Comment 93

[David :Bienvenu]

second fix checked into 1.7

Comment 94

[David :Bienvenu]

see bug 245027 for some fallout of this patch:

basically, if the mailer sends an html attachment with headers like this:

Content-Type: application/octet-stream;
	name="1621805.htm"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="1621805.htm"

we won't display it inline. We used to, before this change. Can we argue that
mailers shouldn't do this, or should we potentially special case .htm(l). The
mailer in this case is:

 X-Mailer: Internet Mail Service (5.5.2653.19)

which I think is this: Freeware Internet Mail Server (IMS) from the European 
Microsoft Windows NT Academic Center (EMWAC). 

http://www.five-ten-sg.com/util/html/ims.htm

Comment 95

[Frank Wein [:mcsmurf]]

(In reply to comment #94)

>  X-Mailer: Internet Mail Service (5.5.2653.19)
> 
> which I think is this: Freeware Internet Mail Server (IMS) from the European 
> Microsoft Windows NT Academic Center (EMWAC). 
> 
> http://www.five-ten-sg.com/util/html/ims.htm

I rather think this header comes from the combo Outlook+Exchange Server, see
http://groups.google.de/groups?q=MS+Exchange/Outlook+header++++X-Mailer:+Internet+Mail+Service+(5.5.2653.19)&hl=de&lr=&ie=UTF-8&selm=39839d08.0109070733.10c3fe5a%40posting.google.com&rnum=1
for a example.