updating the update, as it were

I made an update to my WPF timeline post, but I wanted to make sure that the correction was seen by people who may not revisit that post.

The SRD blog post which revealed that Firefox users were also exposed to the IE vulnerability was published on Tuesday, not Monday. The post is labelled as having been published Monday, and the timeline including that survived review by Microsoft, but nonetheless it was an error that I published, so I’ll own it. To the best of my knowledge, the SRD post which informed us and the world of the Firefox exposure was published on Tuesday after the patch and bulletins were first made available to Windows users.

You guys all about ready to have this thing entirely behind us? Yeah, me too. Me too.

update on the .NET Framework Assistant and Windows Presentation Foundation plugin blocking from this weekend

There’s a fair bit of confusion circulating about what happened, and what’s going to happen next, which is understandable — it’s been confusing! I’ll summarize here what happened, and what’s next.


The add-on and plugin in question have a long and storied history, but for the events of this weekend the timeline basically starts this summer:

July 2009: Mark Dowd, Ryan Smith, and David Dewey present a paper at Black Hat detailing vulnerabilities in Internet Explorer and other software (including some Firefox plugins, such as Google’s Native Client, but not including Firefox itself or the Windows Presentation Foundation plugin).

Tuesday, October 13: Microsoft’s Security Research & Development team posts on their blog revealing that one of the Internet Explorer vulnerabilities in the Dowd and co. paper can be used to attack Firefox users through the use of this IE component in the Windows Presentation Foundation plugin. This plugin was and is distributed as part of Windows .NET Framework 3.5. As part of Patch Tuesday, Microsoft releases MS09-054 and its associated cumulative update, labeled as an Internet Explorer patch. (The bulletin has subsequently been updated to mention Firefox, see below.)

Friday, October 16: Mozilla contacted Microsoft to learn more about the exposure of our shared users. We discussed the nature of the vulnerability as well as the difficulty of uninstalling the plugin and add-on, and agreed that Mozilla should blocklist the add-on and plugin while we sorted out how best to ensure that Firefox users on Windows were protected. The SRP blog post was updated to indicate that Firefox users who applied the patch were protected from the vulnerability.

Saturday, October 17: Based on feedback from users (chiefly enterprise users), our web team began work on mechanisms for an overridable block (“soft block”) capability for Firefox 3.5 users. Discussions with Microsoft indicated that the add-on was a possible vector for the exploit, so it remained blocked.

Sunday, October 18: Microsoft informed us that the add-on (.NET Framework Assistant) was NOT a means for exploiting the vulnerability, and we removed it from the blocklist. The Windows Presentation Foundation plugin was confirmed to be exploitable unless the patch was applied, and remained on the blocklist. The MS09-054 bulletin was updated by Microsoft to include text about Firefox users.

Monday, October 19: We updated our blocklist management system to permit “soft blocks”, and adjusted the blocklist entry for the Windows Presentation Foundation plugin so that users who know they have the appropriate IE patch installed can re-enable the plugin.

Next Steps

Microsoft is monitoring patch adoption rates for the relevant patch, and when it reaches a high level of deployment we will remove the remaining blocklist item. I expect that will be in the next 48 hours at the outside.

Users of Windows 7 RTM are not affected, as the add-on and plugin are not distributed as part of Windows 7. Microsoft is working with Mozilla to make the functionality available to Firefox users in a user-controlled way for all operating systems in the future.

Stephanie Boesch, Director of Program Management at Microsoft, coordinated with Mozilla on this issue, and I want to thank her for her responsiveness and help throughout. She says: “Security is a top priority for all Microsoft customers, and we jointly decided the best course of action was to temporarily block the plugin and add-on while Firefox customers applied the Internet Explorer Security Update. We appreciate Mozilla’s shared commitment to protecting our mutual customers and look forward to working more closely with them in the future on such issues.”

Updated (Wed, Oct 21): fixed a timeline error caused by the SRD blog post having an incorrect publishing date on it, which even survived MSFT review of the timeline. The SRD post was published on Tuesday, not Monday.

[Comments are closed on my blog, but you can leave comments at the Mozilla Security Blog post on the topic if you'd like.]

.NET Framework Assistant blocked to disarm security vulnerability

I’ve previously posted about the .NET Framework Assistant add-on that was delivered via Windows Update earlier this year. It’s recently surfaced that it has a serious security vulnerability, and Microsoft is recommending that users disable the add-on if they have not installed IE patch MS09-054.

Because of the difficulties some users have had entirely removing the add-on, and because of the severity of the risk it represents if not disabled, we contacted Microsoft today to indicate that we were looking to disable the extension and plugin for all users via our blocklisting mechanism. Microsoft agreed with the plan, and we put the blocklist entry live immediately. (Some users are already seeing it disabled, less than an hour after we added it!)

Updated to reflect updates to Microsoft blog post. Also, the add-on was confirmed to not be a vector for the vulnerabilites, so it was removed from the blocklist. The plugin is still blocked pending more information about patch deployment rates; work is underway to make the blocking overridable to accommodate enterprises and sophisticated users who know they have installed the IE patch.

dealing with the .NET ClickOnce add-on

As a number of people have reported, a recent update to Microsoft’s .NET Framework resulted in an add-on being installed into Firefox. Shortly after this patch was released through Windows Update, we were in contact with Microsoft to see how to resolve this issue, as we were hearing directly and indirectly from users that they wanted to uninstall the add-on, and were unable to do so through the Firefox Add-on Manager.

Until recently, removing this add-on from Firefox required that users manually edit the registry, but I’m pleased to report that Microsoft has made available a downloadable patch, and has now added it to the knowledge base article on the topic. Once this patch is applied, the add-on can be uninstalled per-user. (On Windows 7 Release Candidate, the add-on is already the fixed version, at least in my own testing.)

The add-on that was delivered through Windows Update is not compatible with Firefox 3.5, so we’re still trying to figure out how to make sure that 250M-or-so users aren’t confused or — worse — scared off of the upgrade when they are informed that this add-on will be disabled. I’ll report back when we know how that’s going to work, hopefully before Firefox 3.5 is released!

[Edit: removed reference to "disabling".]

Happy New Resig!

Hot, or at least warm, on the heels of our addition of Mark Finkle to the Mozilla Corporation developer relations team, I am pleased as punch to announce that John Resig is sidling up beside Mark to add some more firepower to our developer support capabilities. John is an accomplished writer of both code and prose, and seems pretty fired up about putting those twin gifts to work in service of developers, add-on and web-stuff both. He’s jresig on IRC, and as with Mark and Sheppy you’ll see his fingerprints all over our developer support story in the weeks and months to come.

John’s first day was yesterday, but I was still clinging to the last fleeting hours of my Christmas vacation, so I’m a little late with this announcement. He appears to already be drinking ably from the Mozilla fire-hose, and scheming away with Mark on various plots for web domination, so my tardiness seems to not have impaired him too much!

he’s from state college, and he’s here to help

Good evening, Mozilla world. I would like to take this opportunity to introduce you to Mark Finkle, who joins our intrepid Mozilla Corporation ecosystem team on this very day. Mark’s got a ton of software development experience, he writes very well, and he shares the neurochemical defect that makes me really excited about helping people build their own great stuff on top of our great stuff. You’ll certainly see him and his work on IRC, in the wiki, and on our newsgroups/mailing lists soon, if you haven’t yet had a taste. I’m not saying that the Spiderman theme song was directly inspired by his new role here at Mozilla, but it’s hard to deny that wherever there is an extension development hang-up, you may indeed find him there.

Ours is a daunting community to join, tantamount to learning a new language while riding a unicycle across lava, but I have the utmost confidence that he’ll be up and running in a terrifyingly short time, and before long we’ll be wondering what we did without him. In the meantime, if you should see him wandering the source tree looking slightly dazed, please offer him refreshment — his manager is a bit of a dork, and that can be a serious burden to bear.

AMO and the quality bar

addons.mozilla.org has long occupied a special place in the Firefox software ecosystem. It’s the only site in the installation whitelist by default, the default server contacted for update information about add-ons, and where we send users who are looking for hot add-on leads.

That unique position means that there is a lot of value for some add-on developers in being hosted on AMO. Such hosting involves a review process, which I think both reviewers and developers alike would agree is one of the most frustrating parts of the whole system. The intent of the review process is entirely on the side of the angels: help make sure that add-ons are good for users.

The devil, of course, is in the details here. At times, the review bar has been placed entirely too high, in my opinion: otherwise-fine add-on updates rejected because they cause a strict warning to appear in the JS console, for example. In other cases, we’ve had add-ons approved which send some data to a central server, but don’t have a privacy policy listed. The most common and burdensome cases of this latter example tend to be associated with “toolbar-building” services: the ostensible authors of the resultant toolbars typically know very little about what’s being collected or how it’s being managed, which makes for a predictably unsatisfying conversation with reviewers.

(There are other elements of the review process that are inconsistent and difficult, mostly related to needing to reject items for errors in things that the add-on authors can change after the fact without review, but which can’t be helpfully fixed by the reviewers. These are the “easy” implementation artifacts, though, and not really the topic of this post.)

The trade-offs here are painful: adding a standard of “usefulness” or “implementation quality” to the checklist will not only dramatically slow the review process and require more specialized skills among our reviewers, but will also increase the variability between different reviewers’ decisions. Those are all things that I don’t think we can afford to make worse, and both the history and special position of AMO make me tend towards a much more laissez-faire position: if the description accurately describes what the user will get when they install it, especially as far as the collection and management of private information is concerned, then I think we should let the user make the decision about whether they consider the functionality useful. Some popular add-ons duplicate functionality that is already present in the browser, such as preference settings, adding only an alternate means of accessing it, for example, so requiring “significant new functionality” seems to work against the interests of a fair number of users.

At the same time, of course, I think it’s quite desirable to be able to point users at a more “filtered” view of the enormous add-ons space hosted on AMO. We currently have one such view, the recommended list, but that’s not really much of a solution to the broader problem. (It doesn’t try to be, really.)

A minimum rating threshold would be one way to narrow the default search results returned to a user, though it depends on the reliability and resilience of a rating system. Our current one isn’t sufficient to prevent the sort of gaming and distortion that would plague us in such a world, but that’s not to say that a sufficiently robust one couldn’t be developed. (Not “perfectly robust”, mind; just enough to keep the damage well below the gain.)

A simpler system would simply provide a single piece of metadata that could be set by reviewers or administrators using their judgment and likely via some multi-reviewer discussion. This wouldn’t scale as well as the universal rating by users, but would be more resistant to gaming and abuse (and easier to track and remedy if such nefariousness is detected).

This post is already too long, but you can read and write more about various possibilities for rating and approval schemes in the Remora Idea Dump. We’re thinking about and working on ways to help users find good add-ons, in a way that scales across our community, and I suspect it’s something that we’ll be working to improve for some time!