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.
bug 249756 can be used in combination with this
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?
"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.
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.
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.
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] → [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!
Component: Networking → Downloads Panel
Product: Core → Firefox
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.