Firefox Security Model Growth
Okay, I can bet I’m going to get a lot of flack for this post, so before I start, this is only my opinion and is not at all based on actual numbers. The only reason I’m putting a graph here is because I think it’s easier to visually explain. No numbers. Got it? Just opinion. Don’t get all excited here. Okay. Calm yet? Okay, now don’t start reading this post unless you intend to read the whole thing. Ready? Now you may continue reading the post.
The last post I made was describing just a small smattering of some of my personal Firefox woes around the add-ons that I use to personally secure myself from attacks that either I have helped create, or have seen in the wild. Now, truth be told, I use Firefox every day, due to the add-ons that it supports and the ease of testing webapps. And it’s with that that I’m disheartened by my sense of helplessness around updates.
So here’s what I feel is happening over time for security people (not for the regular every day casual web surfer, but indeed, hardcore security folks, like most of the people who read this site). Over time there are upgrades. Those upgrades fix a number holes, and introduce a few others. They also break the add-ons. Those add-ons help fix the broken browser security model. Therefore, for the likes of me and the vulns I actually am affected by, my security is reduced with each new major revision of the browser, making it look something like this:
Sure, the overall security is trending up with time, but there are major gaps in my perceived security while developers catch up to the new codebase. While the numbers and timelines may be way off, the concept (for me at least) is right. I don’t personally see any immediate major benefit from the browser changes - only negative. With time, sure, things get better, but I happen to be in a particularly bad security slump at the moment right there on the right hand side of the graph. The exploit code that I may have been at risk of, for the most part, is neutered by the add-ons, until they stop working. So which is it? Am I trusting the browser to evolve faster than the add-ons or vice versa?
Firefox’s model has always been, “Feel free to contribute, it’s open source!” While this is great in theory, a) My programming skills get me by and not much more - you don’t want my code in your browser holding the Internet together, trust me b) I don’t have access to all the security bugs - most of the worst of which are hidden from view on bugzilla for only a very small select few people to view and c) there are very few people who have the ability to commit code let alone to fix other people’s add-ons.
It’s tempting to get overwhelmed by the helplessness of it all, but then I just remember that none of these plugins fix things like CSRF which helps me ignore that particular issue. So then I just go home and cry myself to sleep. Okay, now rant away, but if you mis-quote me or fail to read everything before commenting, so help me, I’ll make fun of you senselessly.
July 29th, 2008 at 4:57 pm
I actually agree and have had the same concerns, however I think your graph is slightly off as some if the addons that I use are never updated. Which leaves me to do so, and like you, no one wants my code floating around the tubes.
July 29th, 2008 at 5:14 pm
The main problem is add-on authors don’t take the initiative to test their add-ons on release candidates, and thus when people start upgrading when the real version proper is released, they finally move and get things upgraded. I have personally been guilty of this, albeit in different arenas.
Personally, I just refuse to update until all of my most important add-ons work with the new major version. It’s not like Firefox stopped supporting the older version. If they are not being maintained anymore… well, I guess make do (or hack them up with MR Tech).
July 29th, 2008 at 5:57 pm
I address this a different way. If the add-on is not supported immediately with the browser, I “upgrade” it myself. This approach, knock on wood, has never been a problem and my add-ons have always worked.
After saving the most recent version of the XPI add-on file locally, I rename the extension to ZIP and open it. A quick edit of the install.rdf file and you can increase the maxVersion value to something beyond what your current browser version is. Renaming the add-on back to XPI and opening it in the browser will install it on the newer browser version. Should the author upgrade the plug-in for the future, it still is picked up by Firefox as the version number is not changed.
Ignoring ethics, the hassle and the debate over whether the add-on will always work, this approach will close the period of insecurity that you talk about. I consider some of my extensions a critical part of my browser that I refuse to leave inactive for any window of time.
July 29th, 2008 at 7:39 pm
The Nightly Tester Tools add on will also allow you to run older plugins without having to open them up and change the install.rdf. YMMV but I used it for the delicious plugin before it was FF3 capable and it worked fine.
July 29th, 2008 at 7:52 pm
In Soviet Russia, the browser controls YOU!
oh wait …
nevermind
July 29th, 2008 at 9:25 pm
Danny: the nightly tester tools extension allows you to selectively (or collectively) override the compatibility string of extensions that haven’t yet seen updates.
Granted, sometimes, the authors haven’t released an update because it simply doesn’t work yet, so I’d test after forcing the matter before wandering around in the outside world.
July 30th, 2008 at 12:14 am
“none of these plugins fix things like CSRF”
RSnake, you know that one of the few add-ons of yours working with every each Firefox 3 beta does provide protection against a certain class of CSRF attacks (namely POST requests from untrusted to trusted sites), don’t you?
July 30th, 2008 at 12:42 am
Should also be noted that Mozilla put great effort in ensuring that most of the top 50 popular add-ons were ported to Fx 3 before release: it’s not their fault that security is not as popular as, let’s say, downloading or adblocking.
See http://people.mozilla.com/~polvi/threedom/status-bars.html and http://alex.polvi.net/ for background.
Furthermore, an automatic update for Fx 2 has not been pushed yet, and security updates for Fx 2.0.x are being provided for a relatively long time yet, so if you and other “hardcore security folks” are not forced into feeling less safe: just stick with Fx 2 as long as the extra features you need are not ported yet (by the way, I’m already working at SafeHistory/LocalRodeo-like stuff).
July 30th, 2008 at 1:01 am
It’s not just “hardcore security folks”. For every interest group there’s some number of extensions incompatible at release that makes the next version less good (less secure, less capable, less whatever) than the last-version-plus-extensions. We’re currently in that painful “my faves don’t work” transition, barely more than a month since the Firefox 3 release. There’s no dispute that it sucks but that’s why the old versions are supported in parallel for a while.
July 30th, 2008 at 2:22 am
I’m intrigued: why do you feel your programming skills shouldn’t be trusted to hold the internet together? What d’you think’s the difference in mentality between a security guy and a programmer?
July 30th, 2008 at 7:03 am
“What d’you think’s the difference in mentality between a security guy and a programmer?”
One cares about meeting SDLC deadlines (make it work on time and under budget), the other is concerned about the quality (how easy will it be to break this) of the code. Dynamically opposing goals.
July 30th, 2008 at 7:12 am
The Nightly Tester Tools add on doesn’t work with all the add ons. Although it does allow many to run, most of the security add ons still don’t work. The reason for all these bugs is because of rushed release and improper testing. The test if the browser and add ons work rather than if they don’t work. If they actuallly tested the add ons and browsers by trying to break them, they would have far less bugs.
July 30th, 2008 at 7:49 am
I see your point but I think your graph is a little off. When switching to a new FF version you have the initial line trend downwards, to indicate a slow lessening of security. This is not the case you describe however. As soon as you upgrade to a new version, all your addons break and you’re immediately at a lower security level. The security level then slowly starts to increase as people fix their plugins. In other words, the initial line in each major section should start at the low point and be flat, not start high and slope downwards.
July 30th, 2008 at 8:06 am
@Angel One - again this is my perceived level of security of myself and other security people. Not everyone upgrades their browsers all at once. There’s still a number of older FF instances running on machines in our lab, for instance, that I just haven’t gotten around to updating.
July 30th, 2008 at 1:16 pm
Speaking of security tools: the latest Adblock Plus development build allows you to specify a $third-party flag on the filter. It allows for example blocking all third-party scripts with one filter. It also somewhat makes up for LocalRodeo - you can block third-party access to your intranet (it isn’t a 100% protection however).
July 30th, 2008 at 6:43 pm
you can use other addons to secure it a little
but as longest its better then IE its all good
July 31st, 2008 at 5:12 am
@TheHorse13 I’d buy what you say, if that was what he’d said. But RSnake’s saying his code doesn’t have the quality. And since I’d of expected him to care enough to write good code, I was to curious as to why (he perceives) he can’t.
July 31st, 2008 at 11:50 pm
One more: I had a chat with the author of the FoxyProxy extension today, and he says that it can be used in the same way as SwitchProxy - but is a whole lot better maintained. At the same time it gives you more flexibility, you can define that a proxy should be only used for an address matching a certain pattern. But that’s a feature you don’t need to use if you don’t want to.
August 1st, 2008 at 8:01 am
Mozilla should drop that silly manifest version in installations, or at least give developers the chance to list their extensions for future versions. I won’t update my extension due to this fact, really. Pity for those who liked it, but for me it’s a silent protest against it. hey btw Mozilla, where’s my T-shirt?
August 1st, 2008 at 11:23 am
@rvdh
*Opens the extension in winrar and ups the version number*
wee
August 2nd, 2008 at 8:05 pm
I am still running FF2 but intend to update within the next month or so.
August 4th, 2008 at 12:26 am
@rvdh: I’ll dearly miss your extension. Which one is it, by the way? I need to know so I never install it.
There is a very good reason for this “silly manifest version”, extensions are not always compatible with future browser versions and you cannot know in advance whether they will be. If your extensions is so simple that it will never break then the effort changing one version number really shouldn’t be too much for you, right? But if it is non-trivial you really should test the extension in the new version of the browser before you expose your users to user interface breakage, memory leaks, crashes (all typical effects of incompatible extensions that Firefox gets blamed for). If this is too much effort for you, you probably shouldn’t have started developing an extension in the first place (or kept it for yourself once you were done).
Note that nobody requires you to up the version number for dot releases, you can mark the extension as compatible with Firefox 3.0.*. But already in Firefox 3.1 there will be enough changes to justify double-checking.
August 4th, 2008 at 1:38 pm
@Wladimir Palant.
Why being so dishonest? can’t I have my opinion anymore? so here you go: at least I don’t produce Mao Plugins like you do. :p
Back to the topic:
Exact, no-one requires me to chnage it, and so I won’t. Why change the plugin architecture that plugin’s break? why not settle for a one-time implementation of plug-ins that don’t require a version upgrade. By all means, it proves once again that Firefox is far from being a stable browser.