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"

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.

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

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.

(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.

(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.

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

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.

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.

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)

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/

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.

Preparing as dupe target, because it has more information.

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

(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)

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.

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

(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.

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

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.

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.)

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).

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.