Saturday, July 30, 2005

Greasemonkey 0.5 Beta

All of us here in Greasemonkeyland are extremely happy to announce that Greasemonkey 0.5 beta is now available for download. Horray!

It should go without saying, but: this is beta software. There will definitely be bugs. Install at your own risk.


The major news with this release is, of course, security. Greasemonkey 0.5 is much more secure than 0.3.5. Several important classes of attacks have been completely disabled and others have been made more difficult, particularly in Deer Park.
  • In Greasemonkey 0.3.4, it was possible for JavaScript on webpages you visited ("content") to use DOM mutation events, watchpoints, or Mozilla's proprietary __defineSetter__ method to get references to the special GM API functions. This has been fixed by moving user script execution away from content completely. Now, user scripts are executed in a separate object -- a "sandbox" -- which is not part of the content window. That means that content scripts cannot acccess it, and thus, cannot employ any of the tricks above to get access to the special GM APIs.

  • In earlier versions, it was possible to block Greasemonkey itself by redefining certain content DOM methods that it used to inject scripts. This has been fixed in 0.5 by only ever accessing content via the special XPCNativeWrapper objects provided by Firefox for this purpose.

  • It has long been understood and accepted that it would be possible to block individual user scripts by looking at which core DOM methods they try to use and redefining those. This will be a lot more difficult to do in Greasemonkey 0.5 when it is running on Deer Park. On Deer Park, the window and document global variables for Greasemonkey user scripts are also XPCNativeWrappers.
  • It was recently discovered that GM_xmlhttpRequest was able to access the file:// protocol and read local files. This has been fixed.

  • In all previous versions of Greasemonkey, it was trivial for content to monitor what user scripts you ran and get the source code for them. Running Deer Park and Greasemonkey 0.5, it's significantly less likely. It's still not impossible, however, so please continue to not put passwords in Greasemonkey user scripts.
Of course, no software is ever perfectly secure. Greasemonkey's entire point of existence is to mash code from two different trust domains into the same space, so it has been particularly tricky. This will be an ongoing fight. But for now, I believe that there are no known major security issues with Greasemonkey 0.5 and that it is safe to use. I also think that any future fixes will be much easier to make.


Since Greasemonkey 0.5 is actually the combination of a massive security audit and all the new code which was planned for 0.4, there are lots of new features too:
  • GM_registerMenuCommand (documentation forthcoming) now takes extra parameters to add keyboard shortcuts.

  • GM_registerMenuCommand no longer gets confused sometimes when switching tabs.

  • Greasemonkey's previous memory leakage problems have been addressed.

  • A new API, GM_openInTab has been added. You can now use a Greasemonkey user script to open a URL in a new Firefox tab.

  • A new menu item has been added: New User Script, which you can use to start a new script. It adds all the boilerplate text to the file so you can get started typing right away.

For User Script Authors

For the most part, Greasemonkey 0.5 should be perfectly backward compatible with your existing user scripts in Firefox 1.0.x. In some cases, however, it can bite you when it didn't before. Generally speaking:
  • Never add properties or functions to window. It's not safe because content can redefine these functions to mean something other than what you wrote.

    For example, you should never write code like this:
    window.handleClick = function() {
    alert("something was clicked!");
    button.setAttribute("click", "window.handleClick()");

    Instead, do it this way:
    function handleClick() {
    alert("something was clicked!");
    button.addEventListener("click", handleClick, false);

  • When you want to manipulate the DOM, always fully-qualify your expressions with window or document. So if you want to call alert on the current window, say window.alert instead of just alert. By doing this, you are sure to get the real alert method instead of a new one that content has used to overwrite the real one.

    In a future version of Greasemonkey, the ability to call methods and properties of window without this qualification will probably go away, so best to get in the habit now.

  • Keep up with the current Deer Park best practices on the Greasemonkey wiki.

  • Test in Deer Park if possible. Everything that works in Deer Park will definitely work in FF 1.0.x, but the reverse is not true. So it's best to test or develop your scripts in Deer Park for maximum compatibility.

So that's it. If you have any other questions, the Greasemonkey mailing list is, as always, the place to ask them.

Happy scripting!

Wednesday, July 27, 2005

Funny Greasemonkey quotes #17 (of a seemingly infinite series)

... [to win at the internet now], you have to make your site easily hooked into by Greasemonkey. It’s like an arms escalation race, only with hugs and easy-to-use web applications.

-- Patrick Gaskill

Greasemonkey hole proves Firefox is insecure? Not so much.

This meme has been bouncing over the net for the last few days. From Jon Udell's provocatively titled post Greasemonkey in Crisis:
"As the dust began to settle, a debate began, refracted through the lens of ideology. This time there was no Microsoft (Profile, Products, Articles) to blame. The open source underdogs had done this to themselves. And while some would argue it wasn't Firefox's fault -- since Greasemonkey is a user-installed extension -- Firefox took its share of the blame, just as Internet Explorer does when its add-ins cause trouble."
I'd just like to clarify that I don't think this proves anything about Firefox's security. Firefox - just like other browsers - has a extension system that allows users to install and run separately-developed programs within the security context of the browser, after an explicit confirmation and approval process.

The fact that such an extension has a flaw should not reflect on Firefox. The flawed code was developed separately from Firefox. It's completely different than if, for example, the browser itself had a problem which could allow an extension to be installed silently, without any user approval.

Continuing from the article:
Some say that open source software is inherently secure because the “open source process” makes it so. Wrong. Open source software, and the collaborative culture that surrounds it, have surely enhanced Firefox’s security. But also necessary is a disciplined approach to reducing the attack surface area.
I'd like to point out that Greasemonkey was the first Firefox extension I had ever written. It got very popular very quickly. The fact that it had a hole only proves that someone new to a platform can create software with holes. This shouldn't come as a surprise to anyone.

Greasemonkey 0.4.x, on the other hand, has had the benefit of much more experience on the part of it's developers. Since it is open, it has also been able to benefit from the review and advice of a community of even more senior developers. If bugs are discovered in it, they will be discussed, fixed, and scrutinizeded openly. And Greasemonkey will again be able to benefit from the advice and review of this broad community.

I think that's the main point that Open Source advocates try to make.

Tuesday, July 19, 2005

Mandatory Greasemonkey Update

Yesterday, Mark Pilgrim discovered and announced a very serious security vulnerability in Greasemonkey. The flaw allows any website which matches at least one user script (even * scripts) to read any local file on your machine, or to list the contents of local directories. The flaw applies to Greasemonkey on all platforms.

I'm working feverishly on a fix for this. But this will take several days. In the meantime, I strongly recommend that everyone either install Greasemonkey 0.3.5, or else disable or uninstall Greasemonkey completely.

Greasemonkey 0.3.5 is a "neutered" version of Greasemonkey, lacking any of the GM* APIs which make Greasemonkey scripts more powerful than regular HTML. This means that scripts which depend on GM* APIs will fail with Greasemonkey 0.3.5.

I have heard no reports of this flaw being exploited, but now that it's public knowledge it isn't safe to continue using any version of Greasemonkey other than 0.3.5. Please either upgrade to 0.3.5 or disable Greasemonkey until I can get a fix finished.

I'm aware of how badly this sucks for many of you. Please accept my deepest personal apologies and realize that I'll do my best to get a fixed Greasemonkey available just as soon as possible.

If you have any other questions, the Greasemonkey mailing list is a good place to ask them.

Monday, July 18, 2005

Please do not put private keys in user scripts (yet)

Joe Gregorio wrote a really interesting piece on about sending encrypted data over insecure networks, using Greasemonkey to decrypt it on the client.

In his demo, Joe lists his private key in the user script source.

Please do not put private information into user script source code, yet

As a side-effect of the way that we are currently injecting user scripts, it's possible for malicious sites to sniff their contents. So, for example, if Bloglines got hacked, or somebody exploited a XSS vulnerability to get Bloglines to include their JavaScript in a feed, then Joe's private key could get stolen.

We're thinking about ways to run user scripts completely separate from the DOM, which would prevent this sniffing from being possible, but it doesn't exist yet. I'll post again here when that happens.


If you are an XPCOM/Mozilla/JavaScript expert, Greasemonkey needs you. We are looking for a way to execute JavaScript programatically with these restrictions:
  1. browser content window is the global object
  2. script runs in same security context as browser content is currently running in
  3. we have the ability to add other global objects of our choosing
I've looked into mozIJSSubScriptLoader, but it does not seem to solve any of these well or 2) at all. Post in the comments or on the Greasemonkey mailing list if you have a solution.