1192821 - Regression: 39.0.3: Greasemonkey's "Location hack" no longer works

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Anthony Lieuallen]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150806001005

Steps to reproduce:

For years, Greasemonkey has advised script authors of a technique called the "location hack":
http://wiki.greasespot.net/Location_hack

In short, set the location to a `javascript:` URL, and that code will execute in the scope of the page.


Actual results:

The Firefox 39.0.3 release broke this.  See user reports:

https://github.com/greasemonkey/greasemonkey/issues/2232

Comment 1

[Loic]

Is there a simple testcase to reproduce the issue?

Comment 2

[Anthony Lieuallen]

Firefox 39.0.3, Greasemonkey 3.4beta1.  Install this script:
https://gist.github.com/arantius/3f4688f99b4e266f2753
(click "raw" link).  Visit this bug page ( https://bugzilla.mozilla.org/show_bug.cgi?id=1192821 ) and nothing happens.  Repeat with Firefox 39.0 and the alert displays.

This is a pointless simple steps-to-reproduce script, that only demonstrates the issue.

Comment 3

[Gingerbread Man]

Bug 1178058 may have regressed this. It's not public, so I can neither view it to see who should be CC'd, nor can I mark this as blocking it.

Comment 4

[Loic]

Bug 1178058 is about CVE-2015-4495 (PDF exploit) which led to the security release 39.0.3.
https://www.mozilla.org/en-US/security/advisories/mfsa2015-78/

Comment 5

[john.bacon]

Is this bug likely to be fixed in the near future or will I forever be stuck on FF 39.0?

Comment 6

[Boris Zbarsky [:bzbarsky]]

Is greasemonkey running with expanded principals?  Because setting location to javascript: from an expanded-principal script and having it run with the page's permissions was in fact nerfed in bug 1178058.  Is there really no other API an expanded-principal script can use to run script in the page?

Comment 7

[Anthony Lieuallen]

> Is greasemonkey running with expanded principals?

The user scripts (which would need this feature) are executed in an expanded principal sandbox, yes.

Comment 8

[Bobby Holley (:bholley)]

The Location hack should now be totally unnecessary - you can just window.eval() over Xrays.

Comment 9

[Anthony Lieuallen]

That sounds promising, but:

A) If I'm a script executing in an expanded principal sandbox, how do I choose whether I eval in the sandbox scope vs. the content scope?
B) What happens to all the legacy scripts that don't work?

Comment 10

[Bobby Holley (:bholley)]

(In reply to Anthony Lieuallen from comment #9)
> A) If I'm a script executing in an expanded principal sandbox, how do I
> choose whether I eval in the sandbox scope vs. the content scope?

The sandbox global is not a window (just kinda-sorta prototyped to a window). Invoking bareword eval() will give you the eval() on your global, and invoking window.eval() will give you the eval() on the window.

> B) What happens to all the legacy scripts that don't work?

We could try to restore the old behavior without reintroducing the security vulnerability, but I'm pretty disinclined to do that - this risk is extremely high, because the whole world is looking at that code after the chemspill.

How common is the location hack? Can we just make updates to 10 or 20 scripts on userscripts and be done with the problem?

If it's super common, it seems like it wouldn't be too hard to detect them, warn the user, and do a best-effort automatic rewrite that would probably handle 98% of the cases.

Comment 11

[Anthony Lieuallen]

I've confirmed that `window.eval()` is a workable substitute for the location hack ( http://wiki.greasespot.net/index.php?title=Location_hack&oldid=7202 ) for user scripts under Greasemonkey.

It will require a manual update by script authors to switch, but for now I'm comfortable living with that, unless I get significant push back.

I've updated the relevant Greasemonkey documentation:

* http://wiki.greasespot.net/Location_hack
* http://wiki.greasespot.net/Content_Script_Injection