In the previous entry in this series of entries on Greasemonkey and security, an overview of the history of Greasemonkey security was given. An explanation of why that history matters now was also given. And in this entry, the most recent security issues that Greasemonkey has had are the topic. As was mentioned in the last entry, security fixes had been made in the latest release of Greasemonkey that caused some Greasemonkey scripts to not work. The scripts that do not work with this version, version 0.7.20080121.0, are some of those that work with Greasemonkey’s API functions and the unsafeWindow variable. As was said last week, scripts that use functions defined on the remote page (which are accessed through the unsafeWindow variable) could be vulnerable to hostile pages. However, it recently became apparent that use of this variable makes scripts even more vulnerable than previously thought. This new version of Greasemonkey attempts to make scripts that use this variable somewhat less vulnerable to hostile remote page code. And in this entry, this new version of Greasemonkey and the issues it addresses are the topic.
In the last entry here, it was noted that any script that uses functions or properties of the unsafeWindow or unsafeDocument variables should not be trusted, as the remote page can redefine what is accessed through these variables. However, the possibility of the remote page content running code to redefine what is being accessed through unsafeWindow appears to be only one issue that can result when using unsafeWindow. In that last entry, the importance of Greasemonkey keeping remote pages from being able to use its API functions was also emphasized. So one might think that use of both unsafeWindow and these API functions in a script might possibly lead to some very serious security issues. And it has recently been found that this is the case. One individual seemed to want to find out exactly how unsafe it actually was to use unsafeWindow. And that individual determined that some scripts that use unsafeWindow and Greasemonkey’s API functions could possibly give the remote page access to Greasemonkey’s API functions.
It was said that this particular security issue was publicly disclosed. However, I had some difficulty finding information about it through the use of Google searches. I later discovered that I apparently needed to use a different Google service to find information about this security issue. It was after I looked through posts on the greasemonkey-dev group on Google Groups that I came across the information that I was trying to find. It was said here in this discussion on greasemonkey-dev that when unsafeWindow is used, a privilege escalation attack by the remote page can be made so that the remote page code could be able to access Greasemonkey’s API functions. The news about the possibility of the kind of privilege escalation attack previously described was apparently broken there in that group. And it is there in that thread of discussion where one can see that it was the individual who tried to demonstrate why use of the unsafeWindow variable was unsafe who discovered this security flaw.
Proof of concept code can definitely help in supporting claims made about security flaws. And the individual who discovered this security flaw did write code to support that claim. And the support of that claim was made in the form of the JavaScript on this page and a Greasemonkey script one can use with that page. The Greasemonkey script uses the GM_setValue Greasemonkey API function to set a value to be stored by the browser, then it calls a function on that page through use of the unsafeWindow variable. And when viewing the source code of the page, one can see how the page tries to gain access to what called the function, in an attempt to gain access to the GM_setValue function. When using the script with the page, one will see the value stored in Firefox’s settings before and after the function call to the remote page is made. When using the script in the page with earlier versions of Greasemonkey, the value stored that appears in a window that pops up is different from what it was before the function call. This indicates that the remote page successfully gained access to the GM_setValue function and used it. However, when using this new version of Greasemonkey, one will see that the page’s attempt to change a value stored in Firefox’s settings will be unsuccessful. Therefore, this new version addresses this privilege escalation issue, and so the importance of upgrading to this newer version becomes apparent when using the script with these different versions of Greasemonkey. It should also be noted that this issue did not occur when it was tested with the previous version of Greasemonkey on Firefox 3 Beta 2. Therefore, use of this version of Firefox is considered a way of getting around this issue.
The privilege escalation attack demonstrated on the previously mentioned web page was only one example of what could have possibly been done by the remote page when certain scripts were used. The importance of Greasemonkey preventing the remote page code from accessing the GM_xmlhttpRequest function has been mentioned in the previous entry here. And cross-domain requests were a possibility, as the remote page code could obtain references to other API functions in an attack similar to the one carried out by the the proof of concept code. In addition, in the greasemonkey-dev group, it was said that the remote code could have accessed other information, including the source code of the script. Considering that sensitive data is sometimes stored in the source code of scripts and in the settings stored in the browser that should only be accessible to certain Greasemonkey scripts, this was a serious issue. And it was an issue similar to Greasemonkey’s previous security issues that were outlined here previously. In addition, in an exploit similar to one that was described in the first part of this series of entries here, the GM_xmlhttpRequest function could have been used to send this leaked sensitive data to any location on the web. Although scripts could no longer access files stored on a user’s hard drive, this was an issue that needed to be addressed. Source code leakage and API leakage issues were found to be a possibility again, as they were in Greasemonkey 0.3. These issues may have been on a smaller scale as much fewer scripts had been affected by these more recent security issues, although this was still a problem that needed to be solved.
The fix for this issue came out about a week after the issue was first reported on greasemonkey-dev. The announcement of the new version of Greasemonkey was made here on Greasespot by Greasemonkey creator Aaron Boodman. And in this entry on Greasespot that announced this new version, Boodman mentioned the security issues the new version addresses, and that these security fixes result in some scripts not working with this new version. A link to an article on the Greasespot wiki on the compatibility of scripts with the new version was also there in that entry. It is quite important that script authors who have written scripts that use both these API functions and the unsafeWindow variable refer to that page on the Greasespot wiki, as it mentions a workaround to fix scripts that may be broken. Some might have considered themselves inconvenienced by not having their scripts work with the new version of Greasemonkey. However, when using scripts that use the unsafeWindow or unsafeDocument variables, one takes the risk of having these scripts not do their intended function. And it may be better for them to not work at all than it is to run the risk of having the remote page code perform malicious activity.
Having said this, the most serious security issues that Greasemonkey has may not be considered inherent to Greasemonkey itself. It is certain scripts that Greasemonkey can use that can be considered the most serious security-related issues when Greasemonkey is used. Greasemonkey makes some attempts at preventing scripts from being security issues. However, there are scripts that need to use variables that have names beginning with “unsafe” and that is a problem for which no easy solutions exist. The new version of Greasemonkey simply tried to make unsafeWindow as unsafe as it was previously thought to be. And then there is the issue of deliberately malicious scripts, such as those those that steal cookies. Whether or not Greasemonkey can or should prevent this kind of malicious activity on the part of scripts is debatable. For now, it is still important that scripts be checked to see if they could intentionally or unintentionally perform anything undesired. As I have said before, I had been meaning to write about the scripts themselves, the cookie stealing ones in particular, for some time. And in the next and final entry in this series of entries on Greasemonkey and security, the topic will be the scripts themselves.