741050 - Downloads initiated by other tabs are misleading

Status: NEW

(Firefox :: File Handling, defect)

Description

[Michal Zalewski]

Hey,

I'm guessing this is somewhat undesirable:

http://lcamtuf.coredump.cx/bingdl/

Firefox is the only browser that bothers to outline the origin of the download in the resulting prompt, but still, this is extremely easy to miss in a situation like that. Also consider <iframe>s (even sandboxed ones) that host third-party gadgets or advertisements on a site such as facebook.com - pretty messy.

I think it would be prudent to put any downloads initiated by origin other than that of the top-level document in a window behind an infobar, at the very least.

Comment 1

[Michal Zalewski]

Updated the PoC to be slightly more realistic.

Comment 2

[Daniel Veditz [:dveditz]]

There are three origins in play: the site originating the download, the site the content comes from, and in a spoof case a third site that's the top-level one displayed in the addressbar.  (and maybe a fourth, if we're navigating to a new site but still showing the content of another).

Comment 3

[Michal Zalewski]

FWIW, I can't access 739172, so if it has something relevant / that I have interest in knowing, please summarize. If not, carry on!:-)

Comment 4

[:Gavin Sharp [email: [e-mail]]]

It's essentially a duplicate of this bug, it doesn't really include any additional insights.

Comment 5

[Michal Zalewski]

Heyo,

Just a quasi-monthly ping - any specific plans to tackle this?

Comment 6

[Daniel Veditz [:dveditz]]

This is now public:
http://lcamtuf.blogspot.com/2012/05/yes-you-can-have-fun-with-downloads.html

Comment 7

[Jesse Ruderman]

I think Michal's analysis is correct: a key part of the problem is that the prompt is "attached to the targeted document", which may have nothing to do with the download.

Could we just ignore third-party navigations that result in downloads? Off the top of my head, I can't think of anything likely or legitimate that would break.

Comment 8

[Lucas Adamski [:ladamski]]

This seems like a pretty effective way of tricking a user into download malicious software, so sg:low seems to underestimate the risk.  

Can we prevent cross origin navigation across top level windows?  This is a behavior that always seemed rather strange to me.

Comment 9

[Lucas Adamski [:ladamski]]

Actually I misread the repro.  Its not a navigation window but the download dialog shows up atop whatever window you happen to be looking at.  Still, maybe the right thing is to change the modal download dialog into a tab-specific doorhanger.

Comment 10

[Michal Zalewski]

No, your original assessment was correct. The PoC navigates the target window across domains. Under normal circumstances, the notification is attached to the right window, as shown here:

http://lcamtuf.coredump.cx/fldl/index_nocross.html

Comment 11

[Daniel Veditz [:dveditz]]

Gavin: please find someone on your team to address this issue

Comment 12

[Soroush Dalili]

Any update on this?

Comment 16

[Hallvord R. M. Steen [:hallvors]]

Another PoC:
http://hallvord.com/temp/moz/dl.htm

I don't understand why this has been open for almost two years. At Opera, we considered this a P2 security issue and fixed it promptly. I understand why architectural differences may make it harder to fix in Firefox, but IMO it really should be escalated and we should get an overview of the issues that need work in order to fix this..

Comment 17

[:Gavin Sharp [email: [e-mail]]]

How did you fix it in Opera?

Clicking the button on http://lcamtuf.coredump.cx/fldl/ in the latest version of Opera gives me https://cloudup.com/cYOdTCOC2IR, which seems like essentially the same UI we show.

Comment 18

[:Gavin Sharp [email: [e-mail]]]

(I suppose that's Opera 12.16, not "the latest version" - the updater lied to me. But the latest Chrome-based version works similarly to Chrome, which in addition to being confusing also auto-downloads the file.)

Comment 19

[Hallvord R. M. Steen [:hallvors]]

Apologies for ranting and for any confusion! I no longer have access to the Opera bug system and it turns out I can't trust my memory :-/ I remembered working on it and was overly confident that we had in fact fixed it :-(

Comment 20

[Jesse Ruderman]

If the download is initiated by another tab, we could:
* Switch to that tab
* Hide the dialog until the user switches to that tab

If the download is initiated by a third-party frame in the same tab, we could:
* Show an infobar instead of a dialog
* Ignore the download

(I'm not actually sure if I mean "initiated by" or "happening in", in the case of cross-global navigation.)

Comment 21

[Hallvord R. M. Steen [:hallvors]]

> * Hide the dialog until the user switches to that tab

Sounds good to me.

> If the download is initiated by a third-party frame in the same tab, we
> could:
> * Show an infobar instead of a dialog

That's probably better than ignoring the dialog - I'm pretty sure we'll run into problems otherwise ("Why is downloading attachments broken in my Hotmail?" etc..).

> (I'm not actually sure if I mean "initiated by" or "happening in", in the
> case of cross-global navigation.)

I guess this is the crucial question: does Gecko track enough information about how the navigation is initiated to make these decisions?

Comment 22

[:Gavin Sharp [email: [e-mail]]]

(In reply to Jesse Ruderman from comment #20)
> If the download is initiated by another tab, we could:
> * Switch to that tab
> * Hide the dialog until the user switches to that tab

Something like that is the plan for this bug (see bug 828087).

> If the download is initiated by a third-party frame in the same tab, we
> could:
> * Show an infobar instead of a dialog
> * Ignore the download

This should be filed as a new bug, I think.

Comment 23

[:Paolo Amadini]

I just talked with Philipp and we concluded that the best design for preventing spoofing in this case is to use a tab-modal dialog. This will be based on the design from bug 977037, which will also be applied to the HTTP authentication case, and will handle the iframes case correctly.

We'll thus inherit any throttling mechanism for requests started by scripts, and a clear origin indication that is consistent with what users expect to find in the address bar.

Once a download is confirmed by the user, it will proceed through the usual Downloads Panel interaction.

We might consider allowing identified origins (green in the address bar) and/or safe file types to bypass the modal dialog and start downloads that go directly to the Downloads Panel.

Comment 24

[Marco Mucci [:MarcoM]]

Being removed from Desktop Backlog following review.

Comment 25

[Nicolas Barbulesco]

(In reply to :Paolo Amadini from comment #23)

> We might consider allowing identified origins (green in the address bar)
> and/or safe file types to bypass the modal dialog and start downloads that
> go directly to the Downloads Panel.

I think this would not be a good move. 

First, this would introduce an inconsistency. Consistency gives predictability, and predictability is the best friend of usability.

Secondly, when we decide whether to accept a download or not, usually, we decide whether we want to store the proposed file, not whether it is safe. There are millions of *safe* files on the Internet waiting for me to download them, yet I don't want to download them.

Comment 30

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S4. However, the bug has 5 duplicates.
:Gijs, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 31

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.