Aaron Boodman zboogs at gmail.com
Sat Jul 30 00:34:59 EDT 2005

I got some tips on additional security issues yesterday that I worked on today. 

Basically, it was possible to:

a) use a getter with a counter on details.url to defeat the file://
scheme checking.
b) capture GM's sandbox (and APIs) by overriding eval.apply, or: 
c) capture GM_xmlhttpRequest using

Massive  thanks to T (cc'd) for pointing these out.

a) was easy to fix by being more careful about retrieving details.url
b) was easy to fix by snarfing eval.apply as well as eval and
reassembling them at the time the sandbox gets built
c) was really hard to fix. there's no such thing as __undefineGetter__
so I experimented with detaching GM's scope from Object.prototype
completely and was shocked to find that setting sandbox's __proto__ to
null effectively did this but also allowed all properties to still
resolve correctly. I'm honestly not sure why this works, but guess it
has something to do with the fact that I'm using a reference to
Object.prototype.apply from contentWindow.

T says he doesn't see anymore problems like this, and I don't either.

The only downside is that I'm not sure how to use
contentWindow.setTimeout without being vulnerable to either apply
capture like b), or __defineSetter__ capture, like c), above.

So this breaks bloglines-autoloader.user.js. That's the only one I'm
aware of off-hand.

Let me know if it works at all?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: greasemonkey.xpi
Type: application/x-xpinstall
Size: 50605 bytes
Desc: not available
Url : http://mozdev.org/pipermail/greasemonkey/attachments/20050729/6c6f0473/greasemonkey-0001.bin

More information about the Greasemonkey mailing list