264629 - In HTML mail, a forged URL can easily target an hidden attachment

Status: RESOLVED DUPLICATE of bug 254913

(Thunderbird :: Mail Window Front End, enhancement)

Description

[Jean-Marc]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041007 Firefox/0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041007 Firefox/0.10

In a MIME-formatted message, one part is text/html. In that part, you can have
this :
<a href=3Dcid:(Content-ID #2) height=3D0
width=3D0>www.yahoo.com/inbox/dromaouira/read.php?sessionid-8165</a>
In another MIME part, you have :
 Content-Type: audio/x-wav;
 	name="message.scr"
 Content-Transfer-Encoding: base64
 Content-ID:<(Content-ID #2)>
 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 [...]
This means that by clicking on the forged URL, you open an infected screensaver.
1. The screensaver is not shown as an attachment in the headers pane (as it
should), a minor problem I reckon.
2. The file name should be put clearly BEFORE the malicious URL itself. So it
could be spotted and the forgery be obvious !
All right, after I click, there's a window clearly mentioning the file name, and
with the "open" function disabled. However IMHO the user should be aware of this
before.
Tedious workaround : hover on each URL you see and read the status bar.

Reproducible: Always
Steps to Reproduce:
1. Open the malicious message
2. Click on the wrong URL
3. The "save as ..." popup window appears, and not Firefox !

Actual Results:  
My antivirus woke up.

Expected Results:  
TB should have shown the file name first and the user (me) wouldn't have clicked
on the URL, seeing the forgery.

Comment 1

[Jean-Marc]

Attachment: The message source (attachment edited, as it was a virus)

Comment 2

[Jean-Marc]

Attachment: Screenshot (made with the cursor hovering over the URL)

Comment 3

[Jean-Marc]

Not *really* a bug after all.

Comment 4

[Mike Cowperthwaite]

(In reply to comment #3)
> Not *really* a bug after all.

Meaning what -- should this bug be closed?  If so, please update the bug's 
status as   Resolved | WorksForMe  (or perhaps Invalid).

Comment 5

[Juan Rey]

Severity should be changed. I think it is a security issue more serious than an
enhancement.

Comment 6

[Jean-Marc]

(In reply to comment #4)
> (In reply to comment #3)
> > Not *really* a bug after all.
> 
> Meaning what -- should this bug be closed?  If so, please update the bug's 
> status as   Resolved | WorksForMe  (or perhaps Invalid).

Meaning that it's more of an enhancement than a real bug. But it's still there !

And to answer Juan Rey, it's a security issue, yes, but quite minor, as the
dialog window disables the option to execute the attachment right away. So a
simple click doesn't run the virus at all.

Comment 7

[Mike Cowperthwaite]

(In reply to comment #0)
> Expected Results:  
> TB should have shown the file name first and the user (me) wouldn't have
> clicked on the URL, seeing the forgery.

Provide more detail about this expectation, please.  Show the file name where?  
How can this be handled in a way that doesn't interfere with the rendering of a 
message with a link that legitimately points to an attachment?

Comment 8

[Juan Rey]

(In reply to comment #6)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > Not *really* a bug after all.
> > 
> > Meaning what -- should this bug be closed?  If so, please update the bug's 
> > status as   Resolved | WorksForMe  (or perhaps Invalid).
> 
> Meaning that it's more of an enhancement than a real bug. But it's still there !
> 
> And to answer Juan Rey, it's a security issue, yes, but quite minor, as the
> dialog window disables the option to execute the attachment right away. So a
> simple click doesn't run the virus at all.


Mozilla disables execution, even advanced user realize about filetype but not
about its procedence, an 'untrusted domain'. That is what I think it is reaaly
dangerous, not the filetype itself but its source

Comment 9

[Jean-Marc]

(In reply to comment #7)
> (In reply to comment #0)
> > Expected Results:  
> > TB should have shown the file name first and the user (me) wouldn't have
> > clicked on the URL, seeing the forgery.
> 
> Provide more detail about this expectation, please.
> Show the file name where?  
> How can this be handled in a way
> that doesn't interfere with the rendering of a message
> with a link that legitimately points to an attachment?

I *propose* that if that sort of "rendering" doesn't end with the file name of
the attachment itself, then the link description should be appended with it
between parentheses. This would have given the following underlined link
www.yahoo.com/inbox/dromaouira/read.php?sessionid-8165 (message.scr)

Comment 10

[Juan Rey]

As I have suggested in Bug 264850,
https://bugzilla.mozilla.org/show_bug.cgi?id=264850 , I think that a warning
icon beside the URL, maybe a traffic signal, and an aditional message box on
click would be enough.  

Comment 11

[OstGote!]

IMHO this is a dupe of Bug 254913. See the example screenshot there.

Comment 12

[Jean-Marc]

(In reply to comment #11)
> IMHO this is a dupe of Bug 254913. See the example screenshot there.

You're absolutely right, I missed that one. Thanks ostgote and Juan. The only
remaining bit of this bug/enhancement is the fact that the attachment is not
shown as such but I'm pretty sure that it's pointed out somewhere else. Trying
now to get this bug duped, given that I'm the reporter ...

*** This bug has been marked as a duplicate of 254913 ***