Pretty sure it's XBAP's use of mshtml that's the problem for 09-054; 09-061 is a different vuln that is also exposed through some .NET widget.

We just got confirmation from Microsoft this evening that the .NET Framework Assistant add-on (used to provide ClickOnce stuffs) was NOT a vector for this vulnerability, so we've removed it from the blocklist. The WPF plugin is still there, though we're working on a way to let sophisticated users and enterprises override the block if they know that they have applied the relevant IE patch to their system.

o/~ the more you know o/~

http://blogs.technet.com/srd/archive/2009/10/12/ms09-054.aspx says pretty clearly that it's an IE vulnerability: "While the vulnerability is in an IE component", which fits with the information I have. I think perhaps the WPF plugin uses that IE component?

There is no version difference for the plugin or add-on between patched and unpatched systems. That's one reason that this is so messy right now; if we had known about the Firefox aspect of the vulnerability before the SRD blog post, we would have suggested just that sort of version bump.

We have interest in determining if the Firefox user in question has applied the IE patch in question, but we do not have the means.

It is related to IE, because the patch in question is explicitly labelled as affecting Internet Explorer, and makes no mention of the fact that it can impact Firefox users who have not gone out of their way to disable part of .NET Framework 3.5 SP1. (That's one of the things we're working on getting fixed, as it happens.)

I believe that by tomorrow you will have a number of options, though switching browsers is certainly one of them. I hope to post an update to our security blog about it tonight.

(Do your boxes depend on the WPF plugin or the ClickOnce add-on, out of curiosity? And can I ask what you did before Windows .NET Framework 3.5 SP1 installed this plugin? Or are all the apps in question more recent than February? Genuinely interested, trying to learn more about the scope of people's use here.)

There is no war. We decided together that this was the right step to take right now to protect our mutual users, based on our understanding of the problem and outcomes.

We're working on it (today) -- I'm very sorry for the inconvenience!

I (Mike Shaver) am the person who spoke with the person at Microsoft. I'm not going to name them, because that's not my place, but this was not a case of us sticking it to Microsoft -- it was a case of us protecting our mutual users, with their agreement. We're working (today, as I type this) on ways to make the blocklist entry less disruptive for people who have their systems patched up. If we had known about the vulnerability before it was publicly disclosed, we could have done a lot more to make it smooth for users, but timing left us with an unpleasantly reduced set of options.

Yes, sorry, I should have said that we can't distinguish it without custom code pushed through a patch, because it doesn't affect any files that we load or touch.