Firefox Greasemonkey Extension Security Problem 443
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?"
What did they expect? (Score:5, Interesting)
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... (Score:5, Interesting)
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.
f ile-leak.html [diveintogreasemonkey.org]
returns the contents of c:\boot.ini, which exists on most modern
Windows systems.
http://diveintogreasemonkey.org/experiments/local
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 [mozdev.org]
Uninstall / Remove (Score:2, Interesting)
Would anyone have that info to post?? Thanx
Possible solution - NoScript extension is great ! (Score:5, Interesting)
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? (Score:4, Interesting)
Re:What should be done. (Score:2, Interesting)
I have stated it here before:
Just like ActiveX controls proved a hole in IE, FireFox's extensions would eventually prove a hole in the XUL based 3rd party FireFox extensions arena now & this browser itself, & thus, your OS etc. as well via this gateway.
This is/was 1 thing FireFox imo, had on Opera (my 'browsing weapon-of-choice' online because it wins the speed test comparisons between them all in the most areas typically, but also because it is the LEAST attacked browser as well that shows the fewest holes per year & is by default, just as feature-laden as IE or FireFox (in their defaults), perhaps even moreso in the latest 8.02)...
BUT, now, that 3rd party development is starting to show some faults in it, like this one. Maybe, just maybe, history was the example in IE... of things NOT to do in browsers.
BUT, on the other hand? ActiveX controls extensions of IE, &/or FireFox?? Give it a LOT more power/ability too!
(Double-edged sword this topic, imo!)
Sure, the 3rd party folks EVENTUALLY patch for it, but this is only 1 that's been discovered... how many others are there potentially?
(Perhaps the Mozilla folks have to setup some kind of "Quality Assurance" test prior to users submitting their stuff to their pages for extensions to firefox if they don't have one already of somekind? Would this even help?? Who knows!)
There are, after all, many hundreds of these things (firefox extensions, when I rarely use FireFox, it is loaded with 30 of them that I found useful/excellent, but some ARE slow to load & tend to slowdown FireFox unfortunately)
Yes again: They DO tend to make FireFox alot more powerful than by default (but, load TOO many or the slower ones? You LAG, & bad @ startup)...
This posting however, just again evidences what I personally thought would eventually show holes/vulnerabilities in FireFox...
Just as ActiveX did for IE.
APK
P.S.=> Is this a "big deal"? Yes, & No... if the makers of it patched for it quickly?? Then not. If there was a large "Window of Opportunity for exploiting it" (relative term time-wise), then yes it was... depends on your viewpoint, & if in fact, you used this FireFox extension, right? apk
it's not any file from your disk (Score:2, Interesting)
It seems rogue pages can read any file from your disk and send it to any site, using an XmlHttpRequest.
Only if the browser has all the rights, which is a very dumb thing to do no matter the platform.
On my main Un*x box, Firefox was installed in a normal user account (using the
I'm pretty sure that Firefox/GM installed in a non-privileged user account under Win2000/XP doesn't allow to access any file from the hard disk either.
I'm not trying to defend poor coding/security practice made by people who certainly should know better, but it's simply misinformation to say that access to the files accessible from a user account is equivalent to "all the files on the harddisk".
Re:Why Uninstall? (Score:5, Interesting)
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... (Score:5, Interesting)
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.
Re:Why Uninstall? (Score:2, Interesting)
I use an extension called NoScript, it disables Javascript by default, and I can turn it on per site, and even make it temporary. It can do that bar like you get when installing extensions or blocking popups, but I just keep the icon down in the status bar.
It's even better than the 'per-tab' control you can get with various buttons, because it not only remembers each site, but it lets you turn on, say, slashdot.org, and not 'falkag.net', which right now apparently has scripts on this page.
The problem is, unless I enable javascript on a page, the damn Greasemonkey scripts don't work on it either.
If a cold is no better than pneumonia... (Score:5, Interesting)
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.
Re:The Firefox XPI model needs re-evaluation... (Score:2, Interesting)
I honsetly belive that the current rules in place by the Firefox developers are well minded and do a good job at keep malware base XPIs from getting into a system. However, I think this whole line of thought is a personal taste as opposed to something that the developers should take onto themselves.
However, I would like to address your first point. Where you stated that XPIs should not be initiated from a web page.
Which the point of this is to allow a cross platform installer. I would hate to think that if you made an extenstion for Firefox, you would have to write an installer for Linux, BSD, Windows, Mac OSX, Solaris, HP-UX, BeOS, SkyOS
Now I understand your concern. It's a very logical concern, but if a user goes to malwarefreaks.blowyourcomputerup.com and installs an XPI from there (even after all the popups that tell that user not to do so) and then the user's computer becomes unusable. Well, I find that the fault of the user and not the developers or the XPI system.
There again. You have some really valid points but you can't keep a person from being a total idiot. I believe the defaults of Firefox give enough security with flexibilty.
Re:The Firefox XPI model needs re-evaluation... (Score:3, Interesting)
Yes, but by no means as great a degree as you seem to think.
I would like to address your first point. Where you stated that XPIs should not be initiated from a web page.
That's correct.
Which the point of this is to allow a cross platform installer.
It's not necessary to allow XPI to be installed by a remote web site to allow a cross-platform installer. You don't need to have files opened in a web page to have a cross-platform "open file". You don't need to have bookmarks opened in a web page to have a cross platform "install bookmarks". I'm not saying "don't use chrome and javascript to install a package", I'm saying "don't allow the installation process to be initiated from a webpage". Let the user select "install extension" from a menu, and then select the file they downloaded, and THEN the current installation mechanism can go forward.
Because if by whitelisting a site you grant webpages opened from that site additional rights (the rights to initiate an install, and whatever other steps are necessary to reach that point) you open yourself up to an exploit using those rights from that site, either by injection through a link (as in the recent security fix) or by simple HTML injection through any form on that site.
[I believe] the current rules in place by the Firefox developers are well minded and do a good job at keep malware base XPIs from getting into a system
I don't. Most of the fixes in the post-1.0 security releases would not have been necessary if the design of Firefox was inherently safe. It's very close, but it's not quite there. Getting it there would not be difficult, nor would it reduce the flexibility of the system, it's just a matter of arranging things so that the default state of any "eval" operation (whether from a 'trusted' script or not) is 'untrusted', and that the operation in which a script's rights are revoked is immutably one-way.
Re:Why Uninstall? (Score:2, Interesting)
If your scripts rely on GM_[set|get]Value, they won't work. The scripts may still run, but what value will they have? For example, I have a script [daishar.com] that is only useful in the presence of GM_*Value and GM_xmlhttpRequest. Without that functionality, my script will add a useless bar to the page and never populate it with any data.
It also breaks one of the biggest features of GM -- the ability to pull data from other sites and integrate it into the current page. Scripts like Book Burro [bookburro.org] are now completely useless. Security is important, and it is the right thing to do to remove this functionality while the GM folks look for a better fix, but it does make GM much less attractive (you're pretty much left with page cleanup scripts now that you can't pull data from other sites).
Any idea why all of the GM_* functions had to go? I can see why GM_xmlhttpRequest could be a problem, but what's wrong with GM_log, or the GM_*Value functions?
Re:It's about time (Score:3, Interesting)
Have you looked at the apache security vulnerabilities? There was only one in 2005, and here is the link to the cve:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN
It's not even about apache, it's about a third party apache-utils. That package isn't even part of my distro. i have no such script called check_forensics.
The only other unpatched issue with apache is this one:
http://secunia.com/advisories/11176/ [secunia.com]
Which is rated as non-critical. And it says it's confirmed for 2.0.46 and lower. The latest version is 2.0.54.
Regardless IIS6 & Apache have both been really good. A lot of IIS's reputation comes from IIS5, and let's face it, it is really well deserved. IIS5 is horribly unsecure without first running the lockdown tool, which not all Win Admin's do!