Slashdot Mirror
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?"
It's about time people start writing some exploits for firefox!
http://www.dreamsyssoft.com
Quick, lets band together with a magician and a warrior and stomp those bow&arrow shootin mofos before they take over the internet!
Just more ammo for the mega-powers to say, "See, when it becomes mainstream, it becomes more insecure. Come back to windows."
Marvelous.
Luke
----
Be smart. Teach others. ChristianNerds.com
"Time to uninstall GM?"
Why not just do what the article says and "Install Greasemonkey 0.3.5"
My lame blog.
The firefox guys should have realized that extensions are a HUGE security threat, possibly even worse than anything that's come out of IE. What they should have done is setup some permissions from the first place, so that you can allow or prevent extensions from performing sensitive operations. Something similar to the Java security model would have been good enough
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.
/. ++
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
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
A severe security issue has been discovered in Greasemonkey versions prior to 0.3.5 as well as the early 0.4 alphas which some people may have installed.
Install Greasemonkey 0.3.5 or uninstall Greasemonkey immediately.
More information on Greaseblog.
Greasemonkey is a Firefox extension which lets you to add bits of DHTML ("user scripts") to any web page to change its behavior. In much the same way that user CSS lets you take control of a web page's style, user scripts let you easily control any aspect of a web page's design or interaction.
For example, you could:
Make sure that all URLs displayed in the browser are clickable links Improve the usability of a site you frequent Route around common and annoying website bugs Use the Coral content network selectively.
Getting started:
Install Greasemonkey 0.3.5. Learn how to use Greasemonkey. Find useful scripts.
Greasemonkey was heavily inspired by Adrian Holovaty's site-specific extension for All Music Guide and the conversation which ensued after he published it. There were tons of sites I wanted to create SSE's for, but fully-fledged firefox extensions proved too cumbersome. I wanted it to be as easy to create an SSE as it is to write DHTML.
The current maintainers are Aaron Boodman and Jeremy Dunck with the invaluable help of an awesome community of user script enthusiasts.
For questions or comments about greasemonkey, please send a message to the greasemonkey mailing list. Copyright © 2000-2005. All rights reserved. Terms of Use & Privacy Policy.
Notice hoe they avoid explaining the problem/solution. They just want you to see these new exciting features, and download it now!
Time is comparison of movement to other movement.
We can blame God for all kinds of things like hurricanes and Godzilla but it's a safe bet that we brought THAT scourge upon ourselves.
EvilCON - Made Famous by
The flaw applies to Greasemonkey on all platforms.
"No one likes working in a hamster wheel, and your shop smells of cedar shavings from here." - TaleSpinner
Personally, someone could read my entire hard drive and it wouldn't bother me much. I don't keep sensitive information on my computer, because any computer connected to the internet should be considered insecure.
Nice try Bill, we know it's you.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
Firefox burns greasemonkey cuz it's made of fat But Seamonkey beats firefox because it extinguishes the fire. Then Greasemonkey beats seamonkey because it can float in water AND walk on land. my 2.56 cents
\u262D = \u5350
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!.
I have been a user for about 10 years. This ends Feb 2014. The site's been ruined. I'm off. Dice, FU
(MAN) Sirs, I am in dire need of a web-browser! The one thus furnished to me by Mr. Gates of Redmond is rickety and unsafe, and prone to inviting the most deadly of spy-ware into my parlor!
(MOZILLA SOCIETY REPRESENTATIVE) Why, good sir, we shall help you forthwith! We have exactly the web-browser that you need! It has been engineered to the most careful of specifications, and its security is without compare!
(MAN) Why then I shall have one immediately!
(LATER)
(RANDOM STREET URCHIN) Sir, I see that you have this day procured a web-browser, which I see under your arm. May I convince you to also take this complex contraption of my own invention, which will attach to your web-browser as a "plug in"?
(MAN) What, what? An inscrutable device of unclear ultimate function furnished by a stranger of whom I know nothing? Yes, yes, why not. Now run along, lad.
(LATER THAT NIGHT, THE CONTRAPTION PROVIDED BY THE STREET URCHIN EXPLODES, SETTING THE WEB BROWSER AFLAME.)
(MAN) What's this? Oh, mama! The web-browser I have this very day recieved from the Mozilla Society has immolated, consuming my drapes and lighting my house aflame. They told me it was secure! Lies! Betrayal! Those Mozilla Society rapscallions! I'll give them what for!
Okay, how's this: Since Microsoft Internet Explorer has a dominant market share, people make pages that work on IE. Some of the pages do not work on Firefox since they use some functionality found only in IE. Greasemonkey can be used to alter some of those pages so that they work on Firefox again.
It's Microsoft's fault that people have to install insecure extensions to make web work like it should have worked in the first place.
You're correct. It was discovered by a white hat.
It should be up to the individuals to decide if they want to make such significant mods to their system as purposefully crippling software.
You mean like in Firefox, where when updates are available all the auto-update feature does is display a little "updates available" icon in a browser window, then offer to install the updates when you click the icon?
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
StudyING it (it takes time) and they HAVE found it is not secure, just like the millions of eyes are supposed to do.
One of them is bound to notice, eh?
So it works! Sweet!
Sam
blog.sam.liddicott.com
Go to "tools", go to "Extensions", click on the greasmonkey extension and click "uninstall" or "update".
multifariam.net -- yet another nerd blog
In 1986 I wrote a Commodore 64 terminal program that allowed BBS' to download and run bits of assembly code onto the user's machine in order to enhance the user's experience. It took about 48 hours before someon posted a message that executed a jump to address 64738 -- system reset.
Bad idea then. Worse idea now, no matter how much supposed security you surround it with.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
I admit that I haven't yet tried out GreaseMonkey, but when I look at the exploit code it raises one really big question. Why isn't there some way to prevent non-user script from accessing the GreaseMonkey objects? Wouldn't this allow the user to retain all the ability they have now while rendering scripts from malicious sites harmless? Seeing as how GM is meant to be a means for the user to use scripts to modify pages, it seems very odd that anything outside of user script would be able to access its functionality.
I realize it's likely due to the nature of Firefox's JS interpreter, but if this sort of separation isn't viable could someone enlighten me as to why?
In the future, all spacecraft will be made of cheese.
Why would you say that a sandbox model is overly restrictive? The Java sandbox model has many routes out; it means that you can specify what permissions an application has, not forbid all of them. The Java model comes with nearly all permissions set to "no", but they can be opened.
That said, I haven't seen a really good way to manage permissions. It's just not practical for an applet to say, "In order to run this, you need these 47 permissions" and expect you to fix that. With cleverness the modeler could create roles with aggregates of permissions, so that you can say, "This app needs access to your browser UI" (like Tabbrowser).
Still, that's asking the user to make a lot of security judgments based on trust. Some extensions/applets/ActiveX should be allowed to modify your hard disk; most shouldn't. How can the user tell?
It's a hard problem, one that I don't have a good answer to. I know Microsoft's solution (based purely on a yes/no trust decision) sucks. But I'd say the problem isn't the over-restrictiveness of the sandbox, but the difficulty of asking the user to manage his/her sandbox well.
IE's vulerabilites are admittedly in the same area. It is not that IE installs bad code, it is that it allows bad code to be installed. I don't see the difference. I am not defending IE at all, but Firefox is starting to quack like a duck too, it seems to me.
Perhaps there is some credibility to the arguement that once usage of a software package becomes widespread enough, there will be people who find ways to use it to their (malicious) advantage, regardless of the built in security features.
And the winner of the Slashdot "Who can be the first to blame Microsoft for a bug in FOSS is..."
The problem is not bugs, the problem is that nobody designed their systems to deal with the real security threats presented in the Internet today.
The principle cause of Microsoft's security problems today was their addiction to 'featuritis' in the 1990s. If you think that the open source community does not have the same problem you need to take a serious look at some FOSS programs.
There is nothing that can't be fixed but first people have to realize that FOSS has just as much need to fix them. Everyone in the security community will tell you that making the source code available does not guarantee that your code will be secured. We have enough trouble getting engineers to review their own code.
We need a new approach to writing secure code. Before that can happen a lot of FOSS people need to loose their complacency. Microsoft is not the enemy here, the criminal gangs are the enemy.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
Gator and Weatherbug are not illegal, sadly - the EULA as justification for inclusion has been upheld. The user is in fact getting a bug fix - the bug that allowed for a major security breach is being removed. You may not like that bug fix, but sucks to be you. GM is not disabled by this update and many scripts will continue to run. Insecure scripts will not.
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.
I would like to first address a lot of the people who are taking this as a chance to really dog Firefox and the Open Source Community as a failure on their part.
I've been arguing that the Firefox XPI model needs to be re-evaluated from a security standpoint for some time now.
1. Installing XPIs should not be initiated from a web page. They should be downloaded and manually installed, like any other application or application plug-in. This would allow any attacks that involve using the installer for privilege escalation to be eliminated.
2. Expanded rights should not be granted to any javascript that has not been explicitly installed.
3. As a corollary to this, any method that leads to an eval should, when run from a script that's part of chrome, unconditionally revoke those rights. A new method that explicitly evals code with greater rights with a name that makes it clear that it's dangerous can be added if it's actually necessary.