navigating an opened window to an XPI (using e.g. w.document.location='foo.xpi') doesn't clear out location bar or page contents

RESOLVED DUPLICATE of bug 358266

Status

()

Core
Security
--
critical
RESOLVED DUPLICATE of bug 358266
8 years ago
7 years ago

People

(Reporter: Alan Baxter, Unassigned)

Tracking

unspecified
Points:
---
Bug Flags:
blocking1.9.2 -
wanted1.9.0.x +

Firefox Tracking Flags

(blocking2.0 -, status1.9.1 wanted)

Details

(Whiteboard: [sg:moderate spoof], URL)

(Reporter)

Description

8 years ago
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.
I can reproduce this
Status: UNCONFIRMED → NEW
Ever confirmed: true
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

8 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."
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.
Component: Security → Security
Flags: wanted-firefox3.6?
Product: Firefox → Core
QA Contact: firefox → toolkit
Whiteboard: [sg:spoof]
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
blocking1.9.1: --- → ?
blocking2.0: --- → ?
Flags: blocking1.9.2?
Flags: blocking1.9.0.18?
Whiteboard: [sg:spoof] → [sg:moderate spoof]
I don't think any NSS bug is indicated here.
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-
> 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?
(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.  :)
(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: ? → ---
blocking1.9.1: --- → ?
blocking2.0: --- → ?
blocking1.9.1: ? → ---
status1.9.1: --- → wanted
Flags: blocking1.9.0.18? → wanted1.9.0.x+
(Reporter)

Comment 10

7 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.
That's not related to this bug. For explanation of the behavior you're seeing, please see bug 240552 comment 38.
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: ? → -
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 358266
(Reporter)

Comment 13

7 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.