download prompt should disappear when the page redirects (via JS Timer) (possible to make a download look like it's from a trusted site)

RESOLVED INACTIVE

Status

()

Firefox
Downloads Panel
RESOLVED INACTIVE
14 years ago
2 days ago

People

(Reporter: Daniel Wang, Unassigned)

Tracking

({sec-low})

Trunk
x86
Windows 2000
sec-low
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:low spoof P5])

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
setTimeout("location.href='HTTPS url'",50);
location.href="http://www2.flingstone.com/cab/sbc_netscape.xpi";

Exploit:
 1. Register a misspelled domain name
 2. Use a iframe to preload a page from the correctly spelled domain
 3. Call the above two functions when the document is fully loaded
Result
A download prompt appears. And if the connection speed is fast, a trusted page
should appear in the browser window.
(Reporter)

Comment 1

14 years ago
Created attachment 152242 [details]
testcase
(Reporter)

Updated

14 years ago
Blocks: 249757
(Reporter)

Comment 2

14 years ago
bug 249756 can be used in combination with this

Comment 3

14 years ago
I see the trusted page in the browser window, but at the same time the download
prompt tells me that the thing I am downloading is from:

  http://www2.flingstone.com/cab/

The item to download is a XPI, so I'm not sure why it doesn't present me with
the XPInstall dialog.

I'm using Firefox:
  
  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040721 Firefox/0.9.1+

If the prompt tells me where the download is from, then what's the big concern?
 Should we make the "from:" section of the dialog more prominent?

Comment 4

14 years ago
"from: xxxx"
in bold bigger text would help and might do the trick...

I can imagine an attack like an affiliate site saying "click here to download
firefox from the mozilla web site", then the mozilla page appearing in the
background, and a rouge copy of firefox getting presented to the user...   
The download dialog should not disappear, imo.  At worst, we should prevent the
original page going away until the downlaod dialog is down.

Note that that does not help bug 249756 at all.

Comment 6

14 years ago
yeah, if you think about the possiblity of the approach taken on
http://bugzilla.mozilla.org/show_bug.cgi?id=249322 added to this bug, then it
adds up to being very serious...  darin's talking to jesse to see if that kind
of exploit might be created.

Comment 7

14 years ago
This dialog should show the hostname and the file extension in bold.  Showing
the filename (which is arbitrary text) in bold is asking for trouble.

I like bz's idea of not navigating to another page while the download dialog is
up.  Then, people who habitually look at the address bar rather than the
hostname in the download dialog will be safer.

Updated

12 years ago
Assignee: darin → nobody
QA Contact: benc → networking

Comment 8

11 years ago
anyone have any current thoughts on this bug? do changes in the extension and download managers make this better or worse?

should this still be security closed?
It seems there are other ways to achieve this.  The original page could open the targeted page in a new tab or window, then fire a download event anyway.  In that case the user is already looking at a different tab and the download is initiated w/o restoring focus to the window that triggered it.  Which I'm thinking that the focus should be on the domain in the download dialog rather than the address bar.

I'm labeling this [sg:low] unless we want to take some modal approach (blur/fade?) to de-emphasizing the currently viewed page when looking at a download dialog.
Whiteboard: [sg:low]
Group: core-security
Keywords: uiwanted
Whiteboard: [sg:low] → [sg:low spoof P5]
Not sure what we can give feedback on here, feel free to tag uiwanted again with specific questions. Possible that I don't understand what the problem is, though!
Keywords: uiwanted
Component: Networking → Downloads Panel
Product: Core → Firefox

Comment 11

2 days ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 2 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.