You might know about some of the more glamorous Firefox 3 security features, but behind the scenes Firefox is protecting you from malicious extensions and plugins through its blocklisting service.
Depicted below is a diagram of how Firefox talks to its blocklist service. This is how it works:
- Every day Firefox downloads an XML document from our blocklist service.
- This tells Firefox if there are any malicious plugins or extensions out there.
- If Firefox detects any of these items on your system, it disables them so you can surf the web safely.
What is remarkable about this is that it covers you from things Mozilla doesn’t even release. One of the things I’ve always been proud of is Mozilla’s dedication to its users, and I think this is a good illustration of how we’re finding ways to make the web better and safer. We don’t just care about Firefox, we care about you — and if you are put in a bad position because of poor security in a third-party plugin, we will be there to cover for you — on our dime.
Extension blocklisting has been available since Firefox 2, and we’ve used it in the past to blocklist extensions that cause major crashes or have security problems. Plugin blocklisting is new in Firefox 3, and this is a pretty big feature given recent security news involving plugins.
All major plugins have had arbitrary code execution issues at some point. Plugins like Quicktime or Flash have had some popular cases where hackers could execute code on your system just by having you load a corrupted Flash object or Quicktime movie. Usually vendors are pretty good about updating once these exploits are disclosed, but with Firefox 3 we’ve added plugin blocklisting so we can protect you if vendors aren’t quick enough to respond or don’t provide an easy way for you to upgrade.
Mozilla doesn’t want to leave you out in the cold, and Firefox’s blocklist service is another tool we can use to look out for you.
It’s important to use this tool responsibly so we have discussed a policy for quite some time. The blocklist policy is in our public wiki, and we welcome any questions about it. Any time we consider blocklisting, we contact the vendor or author of the add-on in question to encourage a quick update and let them know we are considering blocklisting. Decisions to blocklist are made by committee to make sure we are not using this service incorrectly or blocklisting things prematurely without just cause.
To show you what the XML document looks like, here is an example of what we are currently serving:
<?xml version="1.0"?>
<blocklist xmlns="http://www.mozilla.org/2006/addons-blocklist">
<emitems>
<emitem id="fdm_ffext@freedownloadmanager.org">
<versionrange minVersion="1.0" maxVersion="1.3.1">
<targetapplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
<versionrange minVersion="3.0a1" maxVersion="*"/>
</targetapplication>
</versionrange>
</emitem>
</emitems>
<pluginitems>
<pluginitem>
<match name="name" exp="Yahoo Application State Plugin"/>
<match name="description" exp="Yahoo Application State Plugin"/>
<match name="filename" exp="npYState.dll"/>
</pluginitem>
</pluginitems>
</blocklist>
What this does:
- Tells firefox to blocklist the Free Download Manager extension, versions 1.0 thru 1.3.1 for Firefox 3.0a1 and higher.
- Tells firefox to blocklist the Yahoo Application State plugin, for all Firefox versions loading npYState.dll.
Information about the blocklist is always found on mozilla.com’s blocklist info page. To learn more about the service itself, feel free to read more about its specifications.
Overall, the blocklist service is another way Firefox is watching out for you, and even though it doesn’t get much press coverage, it’s a remarkable thing and speaks volumes about how serious we are about keeping Firefox users safe — even from stuff that wasn’t Mozilla’s fault.
morgamic 
Yeah, like confusing the crap out of users familiar with the existing yellow background for https by removing it! What a moronic decision.
If you think that was a bad decision, there are a couple of ways to fix it — one would be to write an extension, the other would be to file a bug and state your case in an RFE.
Hey, you blacklisted Yahoo Application State Plugin and I didn’t even know it! That’s really great news, that plugin caused me lots and lots of trouble. Guess I can remove http://adblockplus.org/en/npYState now.
Btw, “mozilla.com’s blocklist info page” is a dead link.
What’s the likelihood of a DNS hack and a malicious person disabling, lets say, the Silverlight plug–in (or a useful extension, like Weave!) ? 🙂
I also don’t see a way to ignore the blocklist, should I raise a bug for that?
ps, your blocklist link is a 404 on the new mozilla site, you need http://www.mozilla.com/en-US/blocklist/
@Wladimir – thanks, fixed.
@John – right, that’s the correct link — thanks for pointing that out along with Wladimir.
To answer your question, the blocklist URL is https (see extensions.blocklist.url in about:config, which follows suit with other services like AUS and extension update. A man-in-the-middle attack is therefore not a primary concern. If the URL was plain http we’d have a hard time sleeping at night…
It is possible to disable the blocklist. In about:config you can flip extensions.blocklist.enabled to false. I strongly recommend not messing with it, though.
In theory, this is great. But in reality, you don’t block anything (almost). The feature is there in Firefox, but it is not used. What good is that for?
@Jesper — That is a fair point. So far the items we’ve blocklisted are receent top crashers so it has been a quality assurance tool. However, there is already a plan in motion to create a default blocklist.xml that we can ship with Firefox to protect users on their first install before Firefox talks to the online service for the first time. Using the service from both angles should improve coverage.
@morganmic
extensions are for knowledgable users. Bog standards features are there for protect idiot users from themselves. That is what Firefox continues to keep claiming it does. In this case that’s a false claim.
As for the bug, I’ve seen it and the debate was very long. In the end the opinion of someone who lives outside of east coast america and is not employed by Mozilla, means nothing.
I saw your article, I had a comment, I made it. If you don’t like that, why don’t you make comments registration only or simply delete my comment? Don’t hide behind the usual crap that Mozilla is this organisation that can never be criticized because people can change whatever they dont like and that all criticism should be buried in bug reports to be ignored by engineers.
@an0n1 m0us – That’s a pretty absolute and divisive way to look at things. I haven’t seen the bug on that issue, but I am assuming you were outnumbered and you are upset about that. Fact remains, though, that your complaints are about something completely off-topic in relation to this post, so I am not sure why you bothered to troll this blog post, or exactly what your point is. Either way, your anonymity and pointed remarks aren’t going to make people take you seriously, so your tone is pretty self-defeating. There are better ways to channel your frustration with a feature you didn’t want.
Wanted to add that there is an extension that already adds back the yellow background in the address bar for SSL sites:
https://addons.mozilla.org/en-US/firefox/addon/6227
It disables the awesome bar, but it’d be pretty trivial to add options to it.
Yikes! This is certainly a feature I rather not have turned on and had no idea it existed before reading this blog postings.
Anyways, thanks for showing a way to turn this off. It’s too bad that this feature needs to be burried in the about.config, instead of being a checkbox in the security panel.
Does Firefox 3 at least let users know that they have blocked plugins or extensions when an attempt is made to use a blocked plugin or extension? Because I can see it being really frustrating for users wondering why a plugin or extension isn’t working, possibly trying to re-install it to get it working.
I don’t know about other users, but personally if there’s a vulerability, rather read up about it and determine myself whether or not to disable the plugin or extension rather than let Mozilla play Big Brother. Especially, if it’s a plugin I may use on a often and don’t have an issue in trusting that the websites that I visit regularly are not going to try to hack my machine with a recent exploit.
Also taking into consideration, that there’s been recent cases where new security vulnerabilities that have popped up have turned out to be old vulnerabilities that don’t effect the latest version of a plugin. This is what happened with the last reported Flash vulnerability, that was reported as a zero-day exploit for the new version of the plugin, but then several days later it turned out to be an old exploit in an older version of the plugin.
I will not allow software to run on my machine that can be remote-controlled.
It is not Mozilla’s fucking right to alter my software on my fucking machine that I paid for. It is not a matter for them to decide what software can and cannot run on my machine. It’s my fucking machine.
That’s why I stayed with Firefox 2.0, and will find out how to crack the killswitch system, just for freedom’s sake.
That’s definitely one way to look at it, but the world (and the internet) is not so black and white and there is significant value in compromise.
But if this is in regards to the .NET stuff — that anger should be equally sent elsewhere to those who install plugins on your machine without telling you. If we blocklist something that was there without your permission in the first place, is it fair to be so angry at us for trying to do something to prevent exploits from harming people who are unaware of the entire situation?
There is no perfect answer to that dilemma.
Hello Your Future,
Before you look for “cracking the killswitch” system, there’s a checkbox that you can uncheck. The Blocklist doesn’t make running blocked plugins impossible, but it makes users aware of significant security issues, and in this case these plugins and add-ons were installed largely without the knowledge of the users in the first place.