Last Comment Bug 537119 - navigating an opened window to an XPI (using e.g. w.document.location='foo.xpi') doesn't clear out location bar or page contents
: navigating an opened window to an XPI (using e.g. w.document.location='foo.xp...
Status: RESOLVED DUPLICATE of bug 358266
[sg:moderate spoof]
:
Product: Core
Classification: Components
Component: Security (show other bugs)
: unspecified
: All All
: -- critical (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://ha.ckers.org/weird/ffpopup.html
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-29 10:14 PST by Alan Baxter
Modified: 2010-05-19 21:58 PDT (History)
13 users (show)
mbeltzner: blocking1.9.2-
dveditz: wanted1.9.0.x+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
wanted


Attachments

Description Alan Baxter 2009-12-29 10:14:44 PST
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 1 Tanner Filip [:tanner] 2009-12-29 10:18:33 PST
I can reproduce this
Comment 2 Tanner Filip [:tanner] 2009-12-29 10:23:00 PST
This is also fairly critical, and i can reproduce on Linux...
Comment 3 Alan Baxter 2009-12-29 10:28:36 PST
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 :Gavin Sharp [email: gavin@gavinsharp.com] 2010-01-04 01:29:08 PST
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.
Comment 5 Nelson Bolyard (seldom reads bugmail) 2010-01-04 03:02:03 PST
I don't think any NSS bug is indicated here.
Comment 6 Mike Beltzner [:beltzner, not reading bugmail] 2010-01-04 09:15:25 PST
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.
Comment 7 Boris Zbarsky [:bz] 2010-01-04 11:43:54 PST
> 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 Johnathan Nightingale [:johnath] 2010-01-04 11:58:21 PST
(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 :Gavin Sharp [email: gavin@gavinsharp.com] 2010-01-04 13:25:00 PST
(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.
Comment 10 Alan Baxter 2010-01-21 22:39:24 PST
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 :Gavin Sharp [email: gavin@gavinsharp.com] 2010-01-21 22:54:42 PST
That's not related to this bug. For explanation of the behavior you're seeing, please see bug 240552 comment 38.
Comment 12 Johnny Stenback (:jst, jst@mozilla.com) 2010-05-19 14:47:08 PDT
This really does sound like the same issue that's reported in bug 358266. Duping, and not blocking 1.9.3 on this.

*** This bug has been marked as a duplicate of bug 358266 ***
Comment 13 Alan Baxter 2010-05-19 21:58:13 PDT
I'm the reporter and I agree with you, Johnny.  Thank you for duping it.

Note You need to log in before you can comment on or make changes to this bug.