Pretty much every Flash movie on the web today uses Flash Player’s global storage feature to store data on your disk, similar to regular browser cookies. What makes this feature so problematic is the lack of proper control mechanisms. For example, for browser cookies I selected “Keep until I close Firefox” which makes sure that cookies can be set (no site functionality is broken) but won’t survive too long. But this setting won’t apply to Flash data. Same goes for the Private Browsing mode in Firefox 3.1, it has absolutely no effect on Flash. Note also that Flash data is the same for all browsers and all profiles.
Now theoretically you can change Flash settings to address this problem. Of course this feature is so well-hidden that I doubt anybody ever uses it. Still, when I tried all I got was constant nagging: “Do you want to allow this site to write data to your disk?” Honestly, is it so hard to add a “never allow” option? Not to mention that even with the most restrictive settings Flash continues to remember which sites I visited (again, clearing browser history or Private Browsing mode have no effect). But these settings break many sites nevertheless.
XUL overlays are a great mechanism for extending existing functionality. However, there is a catch — any scripts loaded by an overlay are sharing the namespace with the scripts loaded by the original page and the scripts loaded by other overlays (typically from other extensions). So if extension Foo defines a global variable myGreatVar and extension Bar chooses to define a global variable myGreatVar as well, bad things will happen — both extensions will end up accessing the same variable and usually both extensions will behave erratically because of that. Same happens with functions, if two scripts define the same global function the second function definition will override the first. The situation is worst for constants — a constant cannot be redeclared meaning that one of the extensions will cause an error message.
Now this problem isn’t a new one and Mark Ziesemer wrote a nice article suggesting namespaces as a solution a while ago. This blog article even made it into AMO’s text block answers. Unfortunately, I think that these fake namespaces are an awkward and unnatural construct in JavaScript. You will have to spell out your namespace all the time and you will have to force your code into an object oriented writing style (which may or may not be desired). And of course you are still polluting the global namespace, and be it only for the namespace variable.
Since Haploid solved my previous puzzle way too fast, here is another one: what is that page really trying to load? And why is it that NoScript and Adblock Plus disagree so much on that — none of the dozen domains NoScript is showing show up in Adblock Plus and the one request showing up in Adblock Plus doesn’t show in NoScript.
Back in August, at the Firefox Summit, I promised Giorgio Maone to properly analyze NoScript. Trust me, better that than the alternative. And it is not that I forgot. I tried, really. Problem is, Giorgio isn’t a big friend of modularization. Most of NoScript code is contained in two files, one being 2000 and the other whooping 8000 lines long, all of its 500 features nicely intertwined. He isn’t a big fan of documentation either, keeping code comments to a minimum as to prevent code bloat. Finally, he isn’t a big fan of consistency and made sure that each feature is triggered only under its very unique conditions. In short, the code is a mess.
Fortunately, I now have a nice tool for just these cases. On the train from FOSDEM I added the ability to change filters to JavaScript Deobfuscator and worked around bug 475334 to make sure all scripts being executed really show up. It turned out that this isn’t quite enough, XPCOM components are apparently invisible to the debugger and still don’t show up. But at least now I can open JavaScript Deobfuscator, adjust the filters to include “chrome://noscript/” while not excluding anything — and next time I load a page I see exactly what NoScript is doing on page load. There are quite a few things going on there but it is still a lot easier to get an overview than by looking at the source code.
One of the most overused JavaScript features is the eval() function. I have seen it used in very many extensions but only a few actually had a good reason to use it. So I want to go through all the wrong reasons one would use eval().
I spent in total something like 10 hours searching 78 of the top 100 extensions for signs of unsafe interactions with the web (yes, I failed downloading the extensions that are hidden behind a EULA, will do better next time). The result: 14 extensions with severe vulnerabilities (typically the kind of vulnerability that lets a web page take over your browser and even the computer if your browser runs with administrator privileges) and several proof of concept exploits. The good news: I don’t think that I missed too many vulnerable extensions, when I searched for more patterns I just kept finding new issues in the extensions that were already known to be vulnerable. More good news: none of the top 10 most popular extensions made the list. The bad news: many of the remaining extensions didn’t make this list simply because they don’t interact with the web or only interact with the web in ways that are relatively unproblematic. Some others were just too messy to get an overview in reasonable time, so it was impossible to understand whether questionable coding practices actually caused security issues.
Altogether, not too many extensions follow best practices that would protect them from such issues. The percentage is probably lower than for websites. But on the other hand, the potential consequences of vulnerable extensions are not comparable. The conclusion (which isn’t really new): more evangelizing for safe coding practices is needed. I recently published my first article on safe coding practices, more should follow. And AMO needs to push extension authors into abandoning questionable approaches, regardless of whether these approaches currently cause security issues.
Over the last few years I reported a bunch of security vulnerabilities in various extensions and by far the most common issue was: “Extension Foo allows execution of remote code in privileged context”. Typically, an RSS reader extension would take the content of the RSS feed (HTML code), format it nicely and insert into the extension window. The issue that is overlooked here is that the RSS feed could contain some JavaScript code and it would then execute with the privileges of the extension — meaning for example that it would get full access to the browser (cookies, history etc) and to user’s files. pdp discovered a similar issue in the Firebug extension that uses an HTML-based templating system and forgot to sanitize some input received from the webpage. (Clarification: The Firebug vulnerability is a very old one, this wasn’t meant as an example of an open vulnerability)
In my opinion, all these problems could have easily been avoided by choosing the right approach that makes use of the existing security mechanisms in the Mozilla codebase. For JavaScript Deobfuscator 1.5 I had to display JavaScript code from potentially malicious websites in my own window so I decided to take as many precautions as possible. And it is really not that hard.
A few months ago I read a post in the WebSense Security Labs blog: The Ultimate Deobfuscator. Wow, pretty impressive hacking effort and nice tricks to hook JavaScript eval() function and document.write() in Internet Explorer. But couldn’t you use JS Debugger hooks in Firefox to do the same thing with only a few lines of code? And then maybe even more generic because eval() and document.write() are certainly not the only ways to generate JavaScript code on the fly (out of the top of my head: changing window.location to a JavaScript URL, event handler attributes or setTimeout() with a string parameter).
Anyway, I finally took the time and actually wrote that Firefox extension: JavaScript Deobfuscator (source code). It adds a “Watch code execution” menu item to Tools menu, once checked all JavaScript compiled on a web page is posted as a message to Error Console. Nice side-effect: the JavaScript engine reformats the code to make it more readable. Downside: JavaScript performance goes down the drain, so using the browser with that option always switched on really isn’t recommendable.
While I usually spend most of my time with stable browser versions, I still use Minefield frequently. And Minefield builds now have the new Ctrl+Tab behavior again. While this feature will certainly help most users navigate around their tabs, I cannot help myself disliking it. And now I finally understand my problem: usually I don’t even look at the screen when switching tabs.
When I am switching tabs, most of the time I know already which tab I want to switch to and simply press Ctrl+Tab or Ctrl+Shift+Tab the required number of times automatically. The new behavior is extremely irritating then as it is impossible to predict what you need to press to get to the required tab. Now I have to visually check the thumbnail to verify that I am switching to the right tab (I know what the tab header looks like but linking it to the thumbnail still requires a conscious decision). It doesn’t help of course that in the current version it isn’t very obvious which thumbnail is selected right now and this selection is indistinguishable from the thumbnail your mouse happens to hover over right now.
Yesterday I reported a Gecko bug where reproducing required the garbage collector to run. In the following discussion this useful snippet of code appeared:
So if you are suspecting that some issue you are observing is dependent on the garbage collector you can use this to force garbage collector to run. I shared that code at work and promptly got a question: what’s the difference to Components.utils.forceGC()? There we go, yesterday I didn’t even know that there was a way to force garbage collection, and today I already know two!
