276991 - No indication of attachment in some virus laden e-mails

Status: NEW

(MailNews Core :: MIME, defect)

Description

[Joseph Tate]

Although the execution of the virus is very difficult, the fact that there is an
attachment is not evident unless one views the Message Source.  There is no
paperclip icon, nor when the message is open is the attachments pane visible.

Please see the attachments to this bug for an example message and a screenshot
showing the behavior.

I believe this is a security issue, but one that is relatively well known.  I.e.
see point 1. in the description of the poster of bug #264629.  I am opening this
bug so that it gets separate attention.

Message location: IMAP Inbox
Message Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_000_001B_01C0CA80.6B015D10"

Relevant Attachment Content-Type: audio/x-wav;
	name="message.scr"

Comment 1

[Joseph Tate]

Attachment: Warning! Live virus attached. Message which, when loaded, shows no attachments.

Please do not open this attachment on an unprotected system.

This message, when opened through Thunderbird will give no indication of the
attachment until the link in the message body is clicked.

Comment 2

[Joseph Tate]

Attachment: Screenshot showing the "no attachment" status of the message

This attachment illustrates that no paperclip attachment icon appears next to
the message, and no attachment pane is displayed in the preview area.

Comment 3

[Mike Cowperthwaite]

The MIME structure of the attached message is not very unusual:

Top:  Content-Type: multipart/related; type="multipart/alternative";
  Part 1: Content-Type: multipart/alternative;
    Part 1.1:  Content-Type: text/plain;  [empty!]
    Part 1.2:  Content-Type: text/html;
  Part 2: Content-Type: audio/x-wav; name="message.scr"

The 'type="multipart/alternative"' is, I believe, a red herring -- I removed it 
from the message and saw the same behavior.  But it is normal, and in fact 
desirable, for multipart/related (and multipart/alternative) messages to not 
show the paperclip; we usually show it only for multipart/mixed.

(In reply to comment #1)
> This message, when opened through Thunderbird will give no indication of the
> attachment until the link in the message body is clicked.

Not strictly "no indication" -- if you look at the status bar while hovering 
over the link, you'll see the 'mailbox' URL which implies an attachment -- but 
certainly not a very meaningful indication.

Do you mean here that you see the attachment icon being shown after you click 
the link?  I don't get that behavior.  I do see the attachment icon if I use
  View | Message Body As | Plain Text
and then the attachment is seen in the attachment panel as well; I believe this 
is because the plain text portion does not refer to the attached part, so it is 
shown as an attachment as backup.  In the panel, the attachment is shown with 
the icon associated with the audio/x-wav type in the system registry.

What happens if you click the link?  It comes down to how TB is configured to 
handle ".scr" files.  Presumably you haven't set things up to simply open those 
in the "default application"; typically you wouldn't configure to do anything 
with those, so the default action would be Save To Disk.


xref bug 254913.

Comment 4

[Mike Cowperthwaite]

(In reply to comment #3)
 
> What happens if you click the link?  It comes down to how TB is configured to 
> handle ".scr" files.  Presumably you haven't set things up to simply open
> those in the "default application"; typically you wouldn't configure to do
> anything with those, so the default action would be Save To Disk.

Thinking about this more, this is not what I would have expected -- I thought 
Mozilla was more adamant about handling files according to the Content-Type, 
rather than the extension.
If the attachment is opened from the attachment panel, that is what happens; 
but if the link is clicked, it's treated according to the extension.  I've 
opened bug 277046 about this.

Comment 5

[Joseph Tate]

(In reply to comment #3)
> Do you mean here that you see the attachment icon being shown after you click 
> the link?  I don't get that behavior.  I do see the attachment icon if I use
>   View | Message Body As | Plain Text
> and then the attachment is seen in the attachment panel as well; I believe this 
> is because the plain text portion does not refer to the attached part, so it is 
> shown as an attachment as backup.  In the panel, the attachment is shown with 
> the icon associated with the audio/x-wav type in the system registry.

If I switch to View | Message Body As | Plain Text, I see the icon, and if I
switch back to "Original HTML" the icon remains, though the attachment panel
present in the "Plain Text" view disappears.

> 
> What happens if you click the link?  It comes down to how TB is configured to 
> handle ".scr" files.  Presumably you haven't set things up to simply open those 
> in the "default application"; typically you wouldn't configure to do anything 
> with those, so the default action would be Save To Disk.

Save To Disk.

> xref bug 254913.

This bug refers to the phishing involved in trying to get the user to open the
virus.  This bug is simply about the treatment of the attachments, and the
indication thereof.

I also noticed that when switching between "Simple HTML" and "Original HTML"
there is a small box just to the right of the link, but I think that's related
to the iframe not the attachment.

Comment 6

[Mike Cowperthwaite]

*** Bug 238295 has been marked as a duplicate of this bug. ***

Comment 7

[Mike Cowperthwaite]

Bug 162508 was about this same basic problem, and that was closed (as 
WorksForMe, but they really meant either Invalid or WontFix).

Bug 240743 is an RFE for showing multipart/related items as attachments when 
they are not actually displayed in the HTML message.

Comment 8

[Mike Cowperthwaite]

The attachment in bug 254913 is the same as the attachment to this bug.
However, the work on phishing detection (bug 279191) so far has not addressed 
this issue.

Comment 9

[Ralf Hauser]

a releated topic is certainly if malware scripts are executed from inside html
via the iframe tag or via <img src="cid:evilScriptDisguisedAsImage"> as
documented in bug 249004 (the silent certificate import is fixed, but the
underlying general problem not yet entirely)

Comment 10

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 11

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Comment 12

[Karsten Düsterloh]

Preparing as dupe target, because it has more information.

Comment 15

[Karsten Düsterloh]

Raising severity to at least major because of it's security implications.

Comment 16

[Wayne Mery (:wsmwk)]

(In reply to comment #15)
> Raising severity to at least major because of it's security implications.

does this deserve some sg: whiteboard?  (assuming it still exists)

Comment 17

[Joseph Tate]

This still exists in Thunderbird 3.1.7.

To reproduce, save the attachment as foo.eml on your system, then in TB, In the File menu, select "Open Saved Message...".  Then browse to your saved file.  Note that there is no attachment indicator, though an iframe border shows up next to the link.

Comment 18

[Wayne Mery (:wsmwk)]

joe(s), can you attempt and give thoughts?

Comment 19

[Joe Sabash [:JoeS1]]

(In reply to comment #18)
> joe(s), can you attempt and give thoughts?

I can verify that there is no indication that the attachment is there when opening the eml file. However it's a little scary to work with live virus files as in the attached eml file. Note to self..somewhere I saw a demo file that was benign yet was detected falsely as a virus..I should look for that for testing cases like this.
BTW clicking on the infected eml file (not double-click) wanted to open it with Internet explorer, even though Firefox is my default..so be careful.

Also regarding comment 5
Using the old trick to change View>>plaintext to see the attachent in the attachment pane no longer works.
xref bug602718

In the overall scheme of things, it would be nice if attachment were always shown in the attachment pane in all cases, or at least an option to make that happen.

Comment 20

[Wayne Mery (:wsmwk)]

probably the test file you refer to is http://www.eicar.org/anti_virus_test_file.htm

Comment 21

[Joe Sewell]

Concur here. There is absolutely '''no''' indication of any sort of attachment in the resulting window. Thunderbird 3.1.7, Mac OS X 10.4.11.

Comment 22

[Joe Sewell]

A further review of the MIME information just showed me something. The so-called "attachment" is marked with a MIME type of audio/wav, something that is quite common as an inline part of an HTML message. It's like having an email with pictures embedded in it. Even though the pictures *are* attached, they're not traditionally treated as separate items, but rather part of the message itself. I can understand a sound file being treated similarly, although I'm not fond of the idea.

In my opinion the MIME type should override the extension; in this case, for example, it should try to play the "script" as a WAVE file and fail miserably. Then again, it's all too easy to hand off file processing to the OS, which would look at the stupid extension. (I also wouldn't put it past Microsoft to *somehow* allow embedding executable code or scripts in a sound file.)

Comment 23

[Joseph Tate]

The mime type has been spoofed.  Wav files are "safe" so they get through attachment stripping filters on mail servers.  Lots of Phone systems email wav files of voice mail to their users, so it's whitelisted.  The filename though is .scr, which have had a history of viruses.  As you say, if the OS handles it from a tmp file (for example).

Comment 24

[Peter Reynolds]

This is still a problem in the form of bug 472085.  Duplicate it may be of this bug but who is going to try and fix a bug on behalf of a virus, whereas displaying Listserv digests correctly is something that *ought* to be done.   

I am currently set up to receive a Listserv 16.0 Digest (HTML format).  What I get is the list of messages, each clickable, and nothing else *visible*.  If I click on an individual message it opens in a text editor.

What I would like to happen is what happens with Yahoo Groups.  The list of messages is at the top, it's clickable, and when you click it scrolls down to the appropriate place in an HTML-formatted digest.  Clicking "View Message Source" makes it plain that there *is* a scrollable digest.

Comment 25

[Wayne Mery (:wsmwk)]

duplicate?