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.

Timeline

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.

briefly

(Is it really true that I only blog what’s too long to tweet now? Need to think about what that means, but I’m already not sure I like it.)

From John, emphasis mine:

The reason we have a vibrant, open web today is because of millions of little decisions and contributions made by thousands of people in that timeframe — people who work on browsers, people who build web sites & applications, people who evangelize for standards, people who use the web and ask/demand that it be better.

From CNET:

Other questions from the audience ranged from what computer science professors should be teaching to whether Internet Explorer would support HTML 5. Ozzie said he had nothing to announce on the latter front, but added, “It is our commitment to be a world class Web browser, what our competitors like to call a modern web browser. I think you can expect us to do the right thing.”

Very much looking forward to it.

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".]

credit where it’s due

There’s going to be a lot of talk this week coming out of MIX, about IE8. Early reports are interesting, if still often hidden behind “NOT PUBLISHED” links on MSDN, but the most interesting thing I’ve seen yet is their change in IE8 rendering mode default. The specific change is a good one, but even more than that I think it’s very promising as a matter of process.

The original decision to make IE8 default to matching IE7′s legacy rendering mode was made in secret, secret even from many of the web experts in the organizations linked to from Dean’s post. Once the conversation was opened to input from the rest of the world’s experts on web content compatibility, they were able to get to a much better decision, and happily that’s reflected in the updated plans for IE8. I hope that this case helps Microsoft understand more generally that significant web-compatibility decisions are too important to be left to closed groups: the web is simply too big, with too many stakeholders, for that to be a workable path to success. (Not that simply operating under “a standards body” is sure to avoid such secrecy, as they can also have related damage, but they at least tend to have more diverse viewpoints, which is a half-measure of some value.)

I was also heartened that they were able to make such a change after announcing it. We’ve all heard before that the IE team wasn’t able to talk about their plans until they were very certain, because people build businesses on those plans and will be harmed are made after an announcement. The conspicuous lack of bankruptcies attributable to WinFS being dropped from Vista aside, that they were able to listen to “global” feedback and make a significant change based on that feedback gives me hope that a new, more open process may be beginning here. Bravo and thanks to Microsoft for listening genuinely and making a change that I think will have a very positive effect on standards-based content on the web.

Some of the items listed in the “IE8 Readiness Toolkit” look pretty interesting, and in at least one case (the “XDomainRequest” API) seem pretty close to the subjects of some recent discussions in standards groups and various open projects about solving similar problems. I’m not sure if Microsoft proposed their API or semantics to that group, or shared the design thinking that went into their choices, but I’m permitting myself to hope anew!

(In light of my previous post about compatibility liability, I was also very interested to see this titbit:

[...]we do not believe any current legal requirements would dictate which rendering mode a browser must use[...]

It’s much more likely that they’re referencing the Opera suit than that they’re talking about Microsoft representatives’ previous claims of lawsuit risk stemming from changes in new product versions, but it made me smile nonetheless.)

suing and blockading for compatibility

One thing that came up periodically when people on the HTML working group were discussing version selectors was the notion that there is legal liability associated with breaking compatibility. Chris Wilson is the person who most frequently brings up this point (unsurprising, given his affiliation and experiences with IE), though he may well not be the only one. I’ll excerpt one example here:

We (Microsoft) have to be in control of our own destiny there. Unless you’re suggesting that the WG would shoulder the financial burden when we (Microsoft) are sued because we broke compatibility and caused some company’s multi-million-dollar intranet app to break.

And later, though not referring to liability but rather a government “lockout”:

A single government who locks us out of their market because we broke their intranet app (even if they were ua-switching and giving us bad content, and it was “clearly their fault”)? Probably a very big deal.

I have a couple of questions, then, for the combined legal minds of the lazy web:

  • What would be the legal basis for a suit by a customer, given the provisions of typical EULAs which explicitly disclaim pretty much all warranty they can? Let’s assume that the compatibility break is caused by an upgrade to a new version of software (Firefox 2 to Firefox 3, for example) that’s under the control of the customer. You can choose your jurisdiction, and assume the worst case for the vendor having end-of-lifed the previous version, etc.
  • Can anyone find an example of such a suit having been brought?
  • Not a legal question, but very much on my mind: given the impact that IE7 had on Korea, why would they have gone ahead and done the release anyway, if it was such a big deal for them to be locked out of a national market?

I invite your informed, or perhaps just creative, speculation on the topic! Personal attacks on Chris Wilson, or rehashed “Microsoft is evil so they got the illuminati to block Korea’s secret sanctions in the UN” conspiracy theories are not welcome, and might well be moderated out or disemvoweled.

X-IE-Version-Freeze

There are a lot of good posts describing problems with IE8′s version selector feature, so I’ll just leave you to read those for some insight into problems that it creates (and how it pushes the IE-compatibility burden off Microsoft and onto other competing browsers in a very impressive way).

They’ve announced what they’re doing in IE8, and as we know from previous conversations with Chris Wilson, they don’t announce until they’re sure:

[W]e have to be very, very careful to be 100% confident when we announce things like “that’s exactly what we’re doing,” or “that’s the date that we are aiming for.” When we don’t, we tend to get a lot of people upset with us, of course, but it’s not just them being upset with us; it’s actually, it can be damaging their business model if they bet on us releasing something in a given timeframe, or bet on us releasing a given feature, and we don’t ship it

So we’re going to see X-UA-Compatible in IE8, with very high likelihood. It’s positioned as something that other browsers could use — if they wanted to ship multiple rendering engines to make download size a further impediment to competing with Microsoft, say, or totally lock themselves out of the mobile market — and the introductory document has examples like “FF=3″ in it.

And we know from the ES4 discussions that Chris believes in different groups working out proposals together, which is why they didn’t make a specific counter-proposal to the one put forward by TG1, after all:

It’s been pointed out that we haven’t made an alternate proposal – well, I’d kinda hoped we could work it out together. “Open to input” should be the way of the web, should it not?

So that makes me wonder: why were no other browser developers involved in this discussion? I guess that would ruin the protective cloak of secrecy, though I don’t know how else people would work things out together. (If Microsoft knows, they’re not telling, but I guess that shouldn’t be surprising?)

The naming of the header is sort of generic, but unless the next big announcement on the IEBlog is the release of IE8′s source code, “render this like IE8 would” really only helps Microsoft, and I think it works against the promising trend of convergence on open standards.

counting still easy, critical thinking still surprisingly hard

Another security study making the rounds today in which someone who purports to know a lot about analyzing security — whose blog tagline, in fact, cautions that “we should try not to simplify [security] to the point of uselessness” — has decided that a product becomes less secure when the developer fixes and discloses vulnerabilities that they find in-house. What Jeff Jones, a director of Security Strategy at Microsoft, has done is simply counted the number of fixed vulnerabilities reported by each of Microsoft and Mozilla, grouping by labelled severity.

What could be simpler? Perhaps nothing. What could be more useless? Again, perhaps nothing.

You can only count what the vendor wants you to see

If Mozilla wanted to do better than Microsoft on this report, we would have an easy path: stop fixing and disclosing bugs that we find in-house. It is well known that Microsoft redacts release notes for service packs and bundles fixes, sometimes meaning that you get a single vulnerability “counted” for, say, seven defects repaired. Or maybe you don’t hear about it at all, because it was rolled into SP2 and they didn’t make any noise about it.

We count every defect distinctly. We count the ones that Mozilla developers find in-house. We count the things we do to mitigate defects in other pieces of software, including Windows itself and other third-party plugins. We count memory behaviour that we think might be exploitable, even if no exploit has ever been demonstrated and the issue in question was found in-house. We open our bugs up after we’ve shipped fixes, so that people don’t have to take our word for our severity ratings.

While Microsoft’s senior technical staff are trying to get severity ratings dialed down (unsuccessfully; kudos to MSRC for sticking to their guns), we are consistently rounding our severities up when there’s any doubt at all.

More fixes means less security?

Even if the scales were the same, and we were living in a parallel universe in which Microsoft even approached Mozilla’s standards of transparency and disclosure, the logic is just baffling: Jeff is saying that Mozilla’s products are less secure than Microsoft’s because Mozilla fixed more bugs. By that measure, IE4 is even more secure, because there were no security bugs fixed in that time frame; bravo to Microsoft for that!

I use Microsoft’s software products myself; I’m typing this on a machine that’s running Vista, in fact. Not only am I pretty upset that we see Microsoft referencing this report without disclosing that it was written by a Microsoft director of Security Strategy, but I’m also concerned for my own safety. Do people in charge of security strategy at Microsoft really believe that aggressively concealing the count of fixes that do make it out makes a product more secure? Shouldn’t they be trying to fix more bugs, rather than writing reports that would “punish” them for actively improving the security of their users rather than hoping that defects aren’t found by someone who they can’t keep quiet?

Microsoft should be embarrassed to be associated with this sort of ridiculous “analysis”. We don’t pretend that hiding the rate of fixes improves our users’ security in any way, and we never will. We’re transparent and aggressive in dealing with security issues, and 130 million Firefox users are safer for it every day.

relevance, your honour?

The search engine business is a tough one. People are generally pretty bad at knowing how to phrase queries to give them what they want, to say nothing of dealing with spelling mistakes and synonyms and stemming, and you have to do all that work basically instantaneously. The relevance of search results might be the only thing more important than performance in determining if users will stick with your particular product, or make the trivial switch to another one.

So I was pretty surprised to discover how, er, idiosyncratic the search results were on Live Search for what I — perhaps naively — think of as a pretty straightforward query.

When searching for “Firefox”, the user might want to find the home page for the product, or a description of the history of the project, or maybe even a review of the software. Both Yahoo and Google give you some mix of that, with what seem to me to be pretty reasonable orderings of results.

The Live Search results are a little more difficult for me to understand, since they have the Silverlight developer FAQ as the first result, then an article about cross-site scripting, then an article about ASP.NET, and then the Wikipedia page about Firefox. You have to go to the 8th entry to get the product’s home page, well below the fold on my machine at least. I’ve saved off the results, in case you disbelieve me, or for some reason can’t reproduce them yourself.

Maybe Live Search users really are a different breed, if that’s what they would be most likely to want when searching for Firefox; a ballsy market-differentiation move by Microsoft, if so.

(Canadians don’t call their judges “Your Honour”, and Americans don’t spell honour that way, so the title of this post is a somewhat impossible reference, but I figure you’ll let that slide.)