Closed
Bug 537119
Opened 15 years ago
Closed 14 years ago
navigating an opened window to an XPI (using e.g. w.document.location='foo.xpi') doesn't clear out location bar or page contents
Categories
(Core :: Security, defect)
Core
Security
Tracking
()
RESOLVED
DUPLICATE
of bug 358266
People
(Reporter: atb12345, Unassigned)
References
()
Details
(Whiteboard: [sg:moderate spoof])
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6
From yesterday's blog at http://ha.ckers.org/blog/20091228/popup-focus-url-hijacking/, a vulnerability has been demonstrated where a Firefox user could be tricked into installing malicious content while an unrelated, trusted site is displayed in the location bar.
Reproducible: Always
Steps to Reproduce:
1. Got to http://ha.ckers.org/weird/ffpopup.html
2. Click on the "Download the NoScript Firefox Add-on from Mozilla" button
3.
Actual Results:
https://addons.mozilla.org/en-US/firefox/addon/722 is displayed in the location bar, along with its green EV-secure favicon. The user is being asked to Allow the installation of the extension he asked for. Although ha.ckers.org is mentioned in the notification bar, the user could easily overlook the mismatch between that and addons.mozilla.org.
Expected Results:
The location bar should not display the address of a site different from what appears to be the contents of the opened window, including the software being installed.
This bug does not need to be confidential. It's been blogged.
The bug is also present in Fx 3.6 Beta 5.
Comment 2•15 years ago
|
||
This is also fairly critical, and i can reproduce on Linux...
Severity: normal → critical
Flags: wanted-firefox3.6?
OS: Windows XP → All
Hardware: x86 → All
Reporter | ||
Comment 3•15 years ago
|
||
This is bit beyond me technically, but RSnake responds to one of the comments to the blog with:
"the URL bar stays the same, and will continue to stay the same, even after the malware is installed. But also the UI has not been modified either, so that still may not be good enough, even if the URL changed - the UI still matches the malicious site. So the side issue is that a separate domain can change the contents of a child frame even if it’s in a different domain."
Comment 4•15 years ago
|
||
I don't really understand that comment from RSnake. Sites can navigate windows they've opened to arbitrary destinations, including pointing them directly to XPIs - that's not a new discovery, and isn't problematic in and of itself. What's problematic is that we're not making it obvious that that occurred, since the default behavior for linking to XPIs is to just offer the prompt without causing a "navigation" that would blank out the existing page and change the displayed URL.
Flags: wanted-firefox3.6?
Product: Firefox → Core
QA Contact: firefox → toolkit
Whiteboard: [sg:spoof]
Updated•15 years ago
|
Summary: Changing the location of the opened window does not change the location bar properly → navigating an opened window to an XPI (using e.g. w.document.location='foo.xpi') doesn't clear out location bar or page contents
Updated•15 years ago
|
blocking1.9.1: --- → ?
blocking2.0: --- → ?
Flags: blocking1.9.2?
Flags: blocking1.9.0.18?
Whiteboard: [sg:spoof] → [sg:moderate spoof]
Comment 5•15 years ago
|
||
I don't think any NSS bug is indicated here.
Comment 6•15 years ago
|
||
Not a 1.9.2 release blocker. Gavin, in comment 4, I take it to mean that we do pop up the "install XPI?" dialog? We've known that to be something that doesn't adequately describe potential security risks well, alas.
Flags: blocking1.9.2? → blocking1.9.2-
Comment 7•15 years ago
|
||
> What's problematic is that we're not making it obvious that that occurred,
> since the default behavior for linking to XPIs is to just offer the prompt
> without causing a "navigation"
Sort of. The behavior is that of stopping the previous page load and then putting up the prompt. In particular, when I tried this without having the addons page cached on my slow network here I got the XPI install popup while the browser showed a blank page, and the url in the url bar was the addons one and the EV thing was on. That is, we'd started parsing the addons page but hadn't displayed anything yet...
Have we considered making the XPI install thing more like an error page instead of a dialog?
Comment 8•15 years ago
|
||
(In reply to comment #7)
> Have we considered making the XPI install thing more like an error page instead
> of a dialog?
And with that, I cc mossop. :)
Comment 9•15 years ago
|
||
(In reply to comment #6)
> Gavin, in comment 4, I take it to mean that we do pop up the "install XPI?"
> dialog?
We pop up the notification bar, just as we would if evilhacker.com requested an XPI install. The problem is that it's confusing to display the "evilhacker.com would like to install software" notification bar on top of the addons.mozilla.com-with-EV-indicators-showing page, since that "evilhacker.com" text in the notification might be easy to miss.
blocking1.9.1: ? → ---
blocking2.0: ? → ---
Updated•15 years ago
|
blocking1.9.1: --- → ?
blocking2.0: --- → ?
Updated•15 years ago
|
Reporter | ||
Comment 10•15 years ago
|
||
Here's an attack/spoof scenario which I found posted at http://forums.informaction.com/viewtopic.php?p=15493#p15493
Is this the same bug?
1) Load http://forums.mozillazine.org/viewtopic.php?uid=143509&f=48&t=1704235
2) Click on jsview-2.0.5-mod.xpi
Result: The notification bar indicates forums.mozillazine.org instead of the apparent download source, downloads.mozdev.org. Shouldn't the notification bar indicate downloads.mozdev.org too?
It gets worse.
3) Click the Allow button to proceed with the installation.
Result: The software installation popup mentions that the extension is being downloaded from opensource.become.com, a completely different site from either of the other two. This behavior could be exploited in the following attack scenario:
* Attacker at badsite.com creates a malware Fx addon
* Attacker goes to some well-known site (say, goodsite.com) and posts, saying "hey, look at this great addon and what it can do!"; he links directly to the xpi
* Unsuspecting visitor clicks the link and is prompted to allow the installation from goodsite.com
* Unsuspecting visitor clicks "Allow"
* Malware addon is downloaded from badsite.com
* Congratulations, unsuspecting visitor, your PC is compromised.
Comment 11•15 years ago
|
||
That's not related to this bug. For explanation of the behavior you're seeing, please see bug 240552 comment 38.
Comment 12•14 years ago
|
||
This really does sound like the same issue that's reported in bug 358266. Duping, and not blocking 1.9.3 on this.
Status: NEW → RESOLVED
blocking2.0: ? → -
Closed: 14 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 13•14 years ago
|
||
I'm the reporter and I agree with you, Johnny. Thank you for duping it.
You need to log in
before you can comment on or make changes to this bug.
Description
•