Unblocklist WPF plugin for people with MS09-054 installed

RESOLVED DUPLICATE of bug 522777

Status

()

Toolkit
Blocklisting
RESOLVED DUPLICATE of bug 522777
8 years ago
2 years ago

People

(Reporter: sid0, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

<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.
(Reporter)

Updated

8 years ago
Blocks: 522777

Comment 1

8 years ago
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

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

Comment 3

8 years ago
(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.
(Reporter)

Comment 4

8 years ago
Yeah, I just checked that Win7 doesn't have either the addon or the plugin.
OS: Windows 7 → Windows Vista

Comment 5

8 years ago
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)
(Reporter)

Comment 6

8 years ago
(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

8 years ago
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
(Reporter)

Comment 8

8 years ago
(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

8 years ago
Oh yeah, that's got it.

No extension or plugin on Windows 7.

Comment 10

8 years ago
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

8 years ago
(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).
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.
Blocks: 522952

Comment 13

8 years ago
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

8 years ago
(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)
Summary: Unblocklist .NET/WPF addons for people with MS09-054 installed → Unblocklist WPF plugin for people with MS09-054 installed

Comment 15

8 years ago
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

8 years ago
All unblocked now.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 522777
(Assignee)

Updated

2 years ago
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.