I have been blogging about the power and usefulness of a tool called Greasemonkey. I have also explained when Greasemonkey is a good tool for use within the enterprise. But before you rush off and use it in your next IT project, you must understand an important issue with the tool. That issue specifically is Greasemonkey's security model, which was designed to protect benevolent scripts from evil websites. But from IT's point of view, the Greasemonkey security model is inverted - it trusts the wrong people. Within the enterprise, the IT hosted websites are trusted. It is the Greasemonkey scripts that may be evil. This blog entry explains the issue, and discusses some coping strategies.
NOTE: this blog entry was originally posted August 18th, 2007 on my previous blogging system (dev2dev.bea.com). Comments on the old blog were not transferred.
This is part 4 of a series of blog entries on Greasemonkey mashups.
- Blog 1: More Mashups: Using Greasemonkey to Weave New Features into Web Sites
- Blog 2: Building a Greasemonkey Mashup Tutorial
- Blog 3: Greasemonkey in the Enterprise: When is GM the Right Tool for IT?
- Blog 4: Beware of Greasemonkey's Inverted Security Model
- Blog 5: Solving the Greasemonkey Script Versioning Problem
The Power of Greasemonkey
A discussion of the Greasemonkey (GM) security model needs to start first with a discussion of the power of Greasemonkey. Greasemonkey scripts have enormous power, and so a security model is key to its design. In fact, the original version of GM got the model wrong, which led to urgent pleas to uninstall GM until the security model was fixed. The urgency of that issue was due to the danger of misuse of Greasemonkey. And that danger is directly related to GM's power and capabilities.
The first thing to understand about Greasemonkey is that it has full access to the web page. If a web page is displaying sensitive information like account numbers, Greasemonkey can see it. Therefore, a compromised Greasemonkey can do great damage by virtue of the information it can steal.
The second issue to understand is that Greasemonkey is powered by JavaScript and has access to features like event handlers. This can enable GM to snoop on anything the user is doing within the page. For example, a compromised Greasemonkey could capture user input, like the entry of a password.
Finally, Greasemonkey operates at a higher privilege level than normal JavaScript, giving it even more power. The most important capability is the ability for Greasemonkey to be immune to cross domain browser security. Normally, HTTP requests issued from JavaScript (XmlHttpRequest) can only target URLs in the same network domain (e.g. bea.com) as the parent page. This restriction was put in place to help limit (it does not totally prevent) cross site scripting (XSS) attacks. However Greasemonkey, as a plugin, is immune to this restriction. This is a most useful feature when building mashups, but it is does mean that Greasemonkey is operating with higher privileges. It can issue requests to whatever URL it wants, perhaps allowing it to send sensitive data to a malicious web server.
In summary, Greasemonkey is a powerful tool. But just as this power can be put to good use, it can also cause much damage when under the control of malicious parties. The rest of the blog describes how Greasemonkey provides protection, and why IT will have concerns about it in the enterprise.
The Greasemonkey Security Model - Trust the Scripts
Currently, Greasemonkey is a tool in use on the greater world wide web. I don't know the number of people using it, but let's speculate that at most its only a few percent of the users on the web. Let's also speculate that the people using it are fairly sophisticated computer users that know what they are doing. In this situation, we have a small community of users that probably don't attract a lot of attention from the black hats out there. Even if they did, the users have the ability to self-regulate and guard against attackers. Every script is human readable, and so users can look at every script before installing them to determine if the script is safe.
With this understanding of the use case, we can now look at the security model. The Greasemonkey security model operates with the following assumptions:
- Trust the Greasemonkey script; the user installed it and therefore it can be trusted not to abuse the powers described above.
- Do NOT trust the targeted web sites. Do not allow those sites any access to GM objects or APIs.
What this means is that the focus of the Greasemonkey security model is on malicious web sites. This came about because the first security model was vulnerable to such attacks. A well crafted web site could steal cookies and even files off the machine of the unsuspecting Greasemonkey user. The security model was revised in 2005, and great care has been taken to prevent web sites from hijaking the privileges of Greasemonkey to do harm. For a great article on how this was accomplished, read Mark Pilgrim's explanation of XPCNativeWrappers and how they protect GM.
While attacks from malicious web sites should no longer be a problem, Greasemonkey is still vulnerable from certain kinds of attacks. Specifically, the security model does NOT have facilities for detecting or preventing malicious user scripts. Therefore, the user must be careful to only install scripts from trusted sources. This model is in use for the public web, but is it the right model for the enterprise?
The Enterprise Greasemonkey Security Model - an Inversion of Trust
Moving into the Enterprise, the angels and demons flip sides. In the enterprise, IT primarily owns the web sites. Rogue IT employees aside, these sites can be considered trusted and safe. But in this case the GM users aren't as sophisticated, and there is greater potential for them picking up malicious scripts. These are the same users that have been clicking on .EXE email attachments for years. IT cannot trust that this user community will correctly protect themselves from evil scripts.
From IT's point of view, the Greasemonkey security model is inverted - it trusts the wrong people.
Whether this is a fatal flaw that prevents an enterprise from using Greasemonkey universally is a decision IT must own. Personally, I don't think Greasemonkey should be a part of an enterprise wide application roll-out. But I do still think it has it's place in niche solutions. The Greasemonkey Selection Framework introduced in my previous post should help guide when it is the right tool.
Admittedly, it is valid to view any sanctioned Greasemonkey use as reckless, because it could open a Pandora's box. Once users get a hold of it for authorized uses, it may lead to other unauthorized use within the enterprise. This is something for IT to bear in mind when considering if Greasemonkey is an appropriate tool. As a counterpoint, malicious attacks aren't limited to Greasemonkey scripts. .DOC and .PDF files both have been used in the past in attacks, but that has not prevented enterprise use of those technologies.
Malicious Greasemonkey - a Real World Example
To show that Greasemonkey scripts can be a real danger, take a look at this image below. It is a screen shot of the public Greasemonkey script repository, and it currently displays a big warning message. Apparently, a malicious script writer has been publishing evil scripts to the public at large.
One could argue that this proves that the community approach works. Community members discovered the malicious behavior and have taken action to remedy it. But within the enterprise, would the users be able to catch such a problem?
Enterprise Solutions for the Greasemonkey Security Model
Now that you are aware of the problem, let's talk about how IT can solve the problem of the inverted security model. Unfortunately, a server side solution is not attainable. By design, a content page cannot know about or have access to the user script. Therefore a server side solution cannot prevent a malicious script from running on the page. In fact, public web sites that generate their revenue through ads have feared this problem for years. There is no way for these sites to stop the ad blocking Greasemonkey scripts.
We must look to the client for the solution. Unfortunately, Greasemonkey does not currently have a technical solution to this problem. For instance, there isn't a feature that prevents non-IT approved Greasemonkey scripts from being installed. Once the plugin is installed, the user is free to install any script, and there is no way to detect if that script has been tampered with. So if a coworker sends out an email like "Check this out, I updated the script to add a new feature", unwitting users may pick up a malicious script.
Instead, IT must rely on some coping strategies:
- Train workers to treat Greasemonkey scripts with as much suspicion as an .EXE file
- IT must host a read-only web site for all scripts to be published where they cannot be tampered with; do not just throw them on a file system
- Beg the Greasemonkey developers to add a signing feature
Further Reading on the Greasemonkey Security Model
- Mark Pilgrim's explanation of XPCNativeWrappers and how they protect GM. A must read for understanding how it works.
- Original Greasemonkey Fatally Flawed - mail thread discussing the flaw with the original security model.
- Top 10 Firefox Extensions to Avoid - Greasemonkey makes the list because of the security model.
- Evil Scripts in the Public Repository - blog entry talking about how userscripts.org now must carry the warning about the evil scripts.
Final Greasemonkey Blog Post Coming Shortly...
The last post in this Greasemonkey series should be done soon...I will show how I implemented a deployment and versioning system for Greasemonkey scripts.
No comments:
Post a Comment