522851 - Unblocklist WPF plugin for people with MS09-054 installed

Status: RESOLVED DUPLICATE of bug 522777

(Toolkit :: Blocklist Policy Requests, defect)

Description

[Rain [:rain1] (inactive)]

<http://blogs.technet.com/srd/archive/2009/10/12/ms09-054.aspx> says that "Firefox users are protected from CVE-2009-2529 if they install the MS09-054 update." So if there's a way to find out whether MS09-054 is installed, we should unblocklist the addon and plugin for such people.

Comment 1

[Julian Hall]

http://support.microsoft.com/kb/974455 lists versions of files updated by the patch.  I don't know if there's a way of detecting these without updating firefox entirely; if not, the block should be disabled as removing working functionality and requiring an upgrade to reenable it is not acceptable, IMO.

Comment 2

[Jonathan Chang]

You can find out if you have the fix from the command line using "wmic qfe get hotfixid" and searching for KB974455.

Comment 3

[Dave Garrett]

(see discussions in bug 522777)

I think this is WONTFIX in favor of a future version of the affected add-ons.

Also, this bug is listed for Windows 7, but bug 522777 comment 56 says that it's not applicable there. Please change it if that's true or clarify it if not.

Comment 4

[Rain [:rain1] (inactive)]

Yeah, I just checked that Win7 doesn't have either the addon or the plugin.

Comment 5

[Jonathan Chang]

Windows 7 has both the addon and the plugin, since .NET Framework 3.5 SP1 can be installed on it. Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)

Comment 6

[Rain [:rain1] (inactive)]

(In reply to comment #5)
> Windows 7 has both the addon and the plugin, since .NET Framework 3.5 SP1 can
> be installed on it. Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.3)
> Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)

Are you using RC or RTM? RTM is bundled with 3.5 SP1 (easily verifiable with the version number of, say, csc.exe), but doesn't have the plugin.

Comment 7

[James May [:fowl2]]

I'm on RTM and I seem the have the extension (disabled) but not the plugin (does it go away when blocked?).

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-AU; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) ID:20090824101458

Comment 8

[Rain [:rain1] (inactive)]

(In reply to comment #7)
> I'm on RTM and I seem the have the extension (disabled) but not the plugin
> (does it go away when blocked?).

Try a new profile -- the extension's probably a leftover if you transferred your data from XP or Vista.

Comment 9

[James May [:fowl2]]

Oh yeah, that's got it.

No extension or plugin on Windows 7.

Comment 10

[Michael Wu [:mwu]]

Shouldn't we be able to block just the affected versions? The blocklist on 3.5 (client side, at least) has access to the file version number of plugins. ( bug 427743 )

Comment 11

[Dave Garrett]

(In reply to comment #10)
> Shouldn't we be able to block just the affected versions? The blocklist on 3.5
> (client side, at least) has access to the file version number of plugins. ( bug
> 427743 )

The problem is that the version number reported by the plugin didn't change after the problem was fixed (bug 522777 comment 42).

Comment 12

[Matthias Versen [:Matti]]

The plugin file is unchanged on my vista system :
29.07.2008  23:40            70.648 NPWPF.dll

The addon got updated to allow the uninstall but not for the security update:
04.07.2009  23:15    <DIR>          DotNetAssistantExtension

The plugin itself also fails to provide a version number on the NPAPI side as for example flash or java are doing.
The addon provides no Version information in the install.rdf
<em:version>0.0.0</em:version>

That means that there is no way for Mozilla.org to block only the affected Verions unless MS provides an update of both components with new Version numbers.

Comment 13

[Chris Charabaruk]

Successful resolution of this issue relies on two things:

* Microsoft releasing NPWPF.dll with a new version number, and
* Mozilla changing the blocklist so that it only blocks versions older than the new one.

Given that the exploit isn't in NPWPF.dll but in the WPF host process (which was what got patched) I can understand why MS didn't update the version number in the plugin. But if they had the foresight to have actually done that, this wouldn't have turned into such a bloody fiasco.

As for the ClickOnce extension, that's collateral damage, as it actually has nothing to do with the exploit at all. And in fact, blocking it will probably result in quite a few angry helpdesks tomorrow, if it's not unblocked shortly.

Comment 14

[Dave Garrett]

(In reply to comment #13)
> Successful resolution of this issue relies on two things:
> 
> * Microsoft releasing NPWPF.dll with a new version number, and
> * Mozilla changing the blocklist so that it only blocks versions older than the
> new one.
> 
> Given that the exploit isn't in NPWPF.dll but in the WPF host process (which
> was what got patched) I can understand why MS didn't update the version number
> in the plugin. But if they had the foresight to have actually done that, this
> wouldn't have turned into such a bloody fiasco.

Pretty much sums it up. In the meantime, soft blocking is in the works for it so it can be optionally overridden.

> As for the ClickOnce extension, that's collateral damage, as it actually has
> nothing to do with the exploit at all. And in fact, blocking it will probably
> result in quite a few angry helpdesks tomorrow, if it's not unblocked shortly.

Extension was unblocked. (bug 522777 comment 136)

Comment 15

[Dave Garrett]

http://shaver.off.net/diary/2009/10/19/update-on-the-net-framework-assistant-and-windows-presentation-foundation-plugin-blocking-from-this-weekend/
> 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.

Looks like instead of detecting patched/unpatched versions it's just going to get unblocked entirely at some point. It is currently soft blocked with the newly implemented system.

Personally, I'd rather it stay soft blocked and let users decide, but it seems the official plan is to keep this block temporarily just to give time to people to install the update.

Comment 16

[Dave Garrett]

All unblocked now.