Firefox Greasemonkey Extension Security Problem

Mr2001 writes "A recent thread on the Greasemonkey mailing list suggests that the popular Firefox extension is fatally insecure. It seems rogue pages can read any file from your disk and send it to any site, using an XmlHttpRequest. Time to uninstall GM?"

Comments

What did they expect?

[Nytewynd]

If you build an engine that allows you to write scripts that modify any page you view, there are obviously serious security flaws.

Allowing scripts to open files and send them elsewhere is especially bad, but there was a huge security concern to me either way. I like the concept of GreaseMonkey, but choose not to install it.

More details on the exploit...

[octaene]

Here are some more details from the posting thread, which explains why the exploit is so bad...

This particular exploit is much, much worse than I thought. GM_xmlhttpRequest can successfully "GET" any world-readable file on your local computer.

http://diveintogreasemonkey.org/experiments/localf ile-leak.html returns the contents of c:\boot.ini, which exists on most modern Windows systems.

But wait, it gets worse. An attacker doesn't even need to know the exact filename, since "GET"ting a URL like "file:///c:/" will return a parseable directory listing. (And Mac users don't get to gloat either; you're just as vulnerable, starting with a different root URL.)

In other words, running a Greasemonkey script on a site can expose the contents of every file on your local hard drive to that site. Running a Greasemonkey script with "@include *" (which, BTW, is the default if no parameter is specified) can expose the contents of every file on your local hard drive to every site you visit. And, because GM_xmlhttpRequest can use POST as well as GET, an attacker can quietly send this information anywhere in the world.

The above information posted originally by Mark Pilgrim

Possible solution - NoScript extension is great !

[CdBee]

I use Greasemonkey in conjunction with NoScript - an extension which prevents any site from using Javascript unless it is added to the whitelist maintained in the extension.

To run a Greasemonkey script on a page you have to allow that domain or subdomain in NoScript. This prevents Greasemonkey being used on a rogue page as I wouldn't use a script on an uber-dodgy site anyway!.

Re:Why Uninstall?

[CdBee]

Just install NoScript and you're sorted. It will stop any script - Greasemonkey or otherwise - running on any site except those you whitelist. I'm sure most of us only use scripts on sites we trust anyway

Re:Why Uninstall?

[jdavidb]

I thought that GM was a way for me, the web user, to impose some scripted changes onto pages. I didn't realize it was used by site-designers to do anything HTML (+JavaScript, etc.) didn't allow.

I don't want to give site-designers any more power, so if that's prevented by neutering GM, I'm fine with that.

Re:Maybe I'm clueless, but...

[Rits]

Greasemonkey inserts the script directly in the pages, so the GM scripts have the same security context as the page itself. Or so I've understood, correct me if I'm wrong.

In the really integrated solution like Opera has (as opposed to an extension like GM is), userscripts have their own security context. The really powerful functions in Opera's userscript are not available to the page author. All functions in GM, including the most powerful, are available to the page author, and Mark Pilgrim just found out this includes unlimited read access to your local file system.

The GM developers are aware that this is a problem, but haven't developed a better way yet to inject the scripts in the page. So the newly secure release 0.3.5 removes the most powerful functions.

If a cold is no better than pneumonia...

[argent]

Mozilla is just as much of an insecure platform as IE, because they allow plug-ins.

Not quite.

The big problem with IE is not just that it has a plug-in mechanism, but it has a plug-in mechanism that's based on the HTML control (the actual browser component) assigning the right to install plugins to an object (the web page) based on an ad-hoc security model that's based on the location the object is believed to originate. Certificates, security dialogs, and so on... these are layered on top of this, but basically the HTML control is responsible for figuring out if a "dangerous" action should be allowed with no more than hints from the calling applications, and a jargon-filled dialog box that the user has to decide on RIGHT AWAY.

I get calls from my users all the time that are variants on "this dialog box came up and I hit 'yes' without thinking".

So... the control is pervasive, it's used by lots of applications, the API can't be significantly changed without creating a mass upgrade day for every app that uses it, responsibility is placed in the wrong place, and the user interaction encourages mistakes.

Firefox's extension mechanism has a similar problem with its installer, but:

The extension installation mechanism is part of Firefox, not the Gecko HTML display object, so applications using gecko aren't automatically exposed as well.

The Firefox extension API does not depend on the installer's behaviour, it's possible for Firefox to switch to a more secure download-and-install design without breaking any applications.

The user interaction requires three separate steps, and there's no path through those steps that simply answering "yes" by reflex will result in the extension being installed.

In addition, in Windows, there have been a number of attacks that involved tricking the HTML control into thinking that a remotely downloaded object was local... or even already installed. This approach is not possible in Firefox because instead of allowing plugins to run from anywhere except the places it thinks are dangerous, it doesn't allow plugins to run from anywhere except a specific directory that's got a randomly generated name in its path so it can't be targeted by a download.

I would still recommend using a shell other than Firefox around a Gecko- or KHTML- based browser. I use Camino (Gecko) and Safari (KHTML) on Mac OS X, but I'm sure there are equivalents to these for Windows. But regardless, the exposure from using Firefox is so far less than using IE that if Firefox and IE are your only choices... use Firefox.

I do not recommend using the Netscape browser, because of the way it allows the use of either Gecko or the Microsoft HTML control.