Last Comment Bug 558584 - Blocklist Java Deployment Toolkit plugin
: Blocklist Java Deployment Toolkit plugin
Status: RESOLVED FIXED
[sg:vector-critical]
: qawanted
Product: Toolkit
Classification: Components
Component: Blocklisting (show other bugs)
: unspecified
: x86 All
: -- critical with 2 votes (vote)
: ---
Assigned To: Michael Morgan [:morgamic]
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-10 14:57 PDT by Daniel Veditz [:dveditz]
Modified: 2016-03-07 15:30 PST (History)
61 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Java (899.78 KB, patch)
2010-04-17 17:19 PDT, Pete
no flags Details | Diff | Splinter Review
java deployment toolkit 6.0.180.7 (888.96 KB, patch)
2010-04-30 22:18 PDT, murdock
no flags Details | Diff | Splinter Review

Description Daniel Veditz [:dveditz] 2010-04-10 14:57:22 PDT
New exploit released for all versions of the Java Deployment Toolkit. This is not java itself, it's hard to say how much legitimate use it has. I suggest softblocking (severity=1) so those who need it can re-enable it (Firefox 3.5 and later, FF3.0 is EOL).

The exploit does not affect Mac. It's not clear whether it affects Linux (Tavis Ormandy, the reporter, didn't think so but others have said yes).

http://seclists.org/fulldisclosure/2010/Apr/119

I tried the PoC on Windows 7 and it didn't seem to do anything, but maybe UAC defeated it. The advisory itself says Windows XP so this needs to be tested there (qawanted). If this can be confirmed for WinXP this needs to be blocked ASAP as the exploit is fully developed and will easily be copied.

http://lock.cmpxchg8b.com/bb5eafbc6c6e67e11c4afc88b4e1dd22/testcase.html

Note that comments in the PoC also claim the deployment kit can be used to downgrade users (silently!) to a vulnerable version of the JVM. If so that's probably cross-platform (except for mac which doesn't have the deployment kit).

"Java Deployment Toolkit"
npdeploytk.dll   (on windows)
Comment 1 Mike Beltzner [:beltzner, not reading bugmail] 2010-04-10 19:38:27 PDT
Yes, approved, we should block - Dan, do you think there's a point in contacting the vendor?

Morgamic, can we get a patch worked up?
Comment 2 Bernd 2010-04-10 23:02:35 PDT
I tried this on XP with a nightly and the POC did not work as it was missing a plugin. I have installed Java(TM) Platform SE 6 U19     File: npjp2.dll
    Version: 6.0.190.4
    Next Generation Java Plug-in 1.6.0_19 for Mozilla browsers and use java frequently, so it might be that a standard Java run time does not install the deployment toolkit.
Comment 3 Daniel Veditz [:dveditz] 2010-04-10 23:53:08 PDT
Certainly the PoC won't work if you're missing the plugin, that's why blocklisting would be effective. I don't know why it wasn't installed for you, 
I've gotten npdeploytk.dll with every recent JRE I've installed on four or five different windows computers. This is separate from npjp2.dll used to run applets; I've always disabled the deployment toolkit and never had a problem running Java when I wanted to.
Comment 4 Giorgio Maone [:mao] 2010-04-11 01:04:54 PDT
Reproduced on a Win XP machine with JRE 6.0.17 and npdeploytk.dll same version.

Then I upgraded to 6.0.19 and the PoC failed with an "Opening: recv failed" error message box, but when I checked the npdeploytk.dll had not been upgraded (about:plugins still reports it at 6.0.17), so maybe the JRE/plugin mismatch is the culprit.

@Bernd, dveditz
You're very likely to get a "missing plugin" message even when the PoC works, because it instantiates two object elements with different mime types ("old": "application/npruntime-scriptable-plugin;deploymenttoolkit", and "new": "application/java-deployment-toolkit") for historical reasons.

My 6.0.17 deployment plugin, for instance, is registered for the "old" mime type only, hence I got both calc.exe running and the "missing plugin" notification, after I allowed the page to run scripts and plugins from NoScript.
Comment 5 christian 2010-04-13 16:55:21 PDT
Via email, we need to blocklist versions < 6.0.200 (and we need to handle 4 spots such as 6.0.xxx.yy)
Comment 6 christian 2010-04-13 18:59:17 PDT
More verbose info from Oracle...

Fixed version is:
------------------------------------
Java Deployment Toolkit 6.0.200.2

  File: npdeployJava1.dll
  Version: 6.0.200.2
  NPRuntime Script Plug-in Library for Java(TM) Deploy

MIME Type 	Description 	Suffixes 	Enabled
application/java-deployment-toolkit 			Yes

A previous version (Java 6u18 or 1.6.0_18) is:
-------------------------------------
Java Deployment Toolkit 6.0.180.7

  File: npdeploytk.dll
  Version: 6.0.180.7
  NPRuntime Script Plug-in Library for Java(TM) Deploy

MIME Type 	Description 	Suffixes 	Enabled
application/java-deployment-toolkit 			Yes

Also note there as a publicly released _19 as well and the 4th group is the build version.

So blocking npdeploytk.dll < 6.0.200.0 should block the vulnerable plugin builds and allow the updated plugin builds to work
Comment 7 Johnathan Nightingale [:johnath] 2010-04-14 12:59:50 PDT
This sounds like something we want to block as a plugin, not a DLL, so that we can push the block immediately, right?
Comment 8 Johnny Stenback (:jst, jst@mozilla.com) 2010-04-14 14:35:05 PDT
Yes, this is a plugin so we should use the plugin blocklisting here IMO.
Comment 9 Daniel Veditz [:dveditz] 2010-04-15 15:38:12 PDT
Attacks are in the wild, let's do whatever's quickest
http://www.theregister.co.uk/2010/04/14/critical_java_vulnerability_exploited/
Comment 10 Daniel Veditz [:dveditz] 2010-04-15 15:42:18 PDT
Since an updated Java release isn't available /yet/ we could simply block all versions for expediency and then later whitelist the fixed version when it's released.

What is the next step and who takes it?
Comment 11 Matthias Versen [:Matti] 2010-04-15 15:53:15 PDT
There is an update from Oracle (1.6 U20) but it doesn't fix the exploit for all users. A Demo exploit still worked with 1.6 U20 on my vista system and Seamonkey.
Comment 12 Michael Morgan [:morgamic] 2010-04-15 15:55:31 PDT
Alright, so npdeploytk.dll < 6.0.200.0
Comment 13 Michael Morgan [:morgamic] 2010-04-15 16:01:22 PDT
Where is this version number stored?  Right now all I have are:
filename
description
name

Can someone verify which field contains the version string and if it's consistent across different releases of the plugin?
Comment 14 Daniel Veditz [:dveditz] 2010-04-15 17:30:21 PDT
Plugins don't have a real version (yet) so it's custom regexp hackery (which plugin blocklisting supports). For this one the version is in the "name" field:

  "Java Deployment Toolkit 6.0.180.7"
Comment 15 Michael Morgan [:morgamic] 2010-04-15 17:35:20 PDT
Ok, thanks.
Comment 16 Michael Morgan [:morgamic] 2010-04-15 17:54:52 PDT
Alright, so assuming we're doing anything lower than 6.0.200.0 how's this crazy exp:
name = "[0-6]\.0\.[01]\d{2}\.\d+"
filename = "npdeploytk.dll"
Comment 17 christian 2010-04-15 18:10:54 PDT
That won't match anything < 100 unless it is zero padded (don't know if that's an issue we care about)
Comment 18 Michael Morgan [:morgamic] 2010-04-15 18:18:15 PDT
Do they have a rel notes page?
Comment 19 Mike Beltzner [:beltzner, not reading bugmail] 2010-04-16 01:10:55 PDT
http://java.sun.com/javase/6/webnotes/6u20.html is the relnote page for the update that was just released ...
Comment 20 Matthias Versen [:Matti] 2010-04-16 07:18:25 PDT
and here is an article that mentions that the update doesn't fix it for all users : http://www.h-online.com/open/news/item/Java-vulnerability-when-lyric-sites-attack-978283.html
Comment 21 Mike Beltzner [:beltzner, not reading bugmail] 2010-04-16 09:00:31 PDT
Yes, I was trying to get an answer for comment 18, which I believe is on the critical path to us getting this blocklisted, which we should do ASAP as it's an "exploits in the wild" sort of thing.
Comment 22 Michael Morgan [:morgamic] 2010-04-16 18:21:18 PDT
Well, let's just run with it and if it's too aggressive we can adjust.  It's blocklisted now.  I'll update mozilla.com shortly.
Comment 23 Michael Morgan [:morgamic] 2010-04-16 18:25:32 PDT
FYI, block was:
  <pluginItem>
    <match name="name" exp="[0-6]\.0\.[01]\d{2}\.\d+"/>
    <match name="filename" exp="npdeploytk.dll"/>
  </pluginItem>
Comment 24 Ryan 2010-04-17 00:28:48 PDT
Please help I have Java Deployment Toolkit 6.0.170.4 and it hasn't blocklisted is there a way to remove it manually. I don't have much computer know how to remove things any help would be appreciated. I don't know if is the right place to post but i am really worried.
Comment 25 Yet Ding 2010-04-17 02:04:59 PDT
Shouldn't Tb block it too? Mine doesn't.

Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
Comment 26 Alice Wyman 2010-04-17 07:03:38 PDT
(In reply to comment #24)
> Please help I have Java Deployment Toolkit 6.0.170.4 and it hasn't blocklisted
> is there a way to remove it manually.  

Find and remove any copies of "npdeploytk.dll" (or rename to "Xnpdeploytk.dll", which is what I did). Ref: http://www.kb.cert.org/vuls/id/886582

Related forum topics:
http://forums.mozillazine.org/viewtopic.php?p=9183035#p9183035
http://forum.avira.com/wbb/index.php?page=Thread&threadID=111317
Comment 27 Shriramana Sharma 2010-04-17 07:21:02 PDT
People the page https://www.mozilla.com/en-US/blocklist/ says "versions 6.0.200.0 and older" but in the above description it says nothing about version _20 also being affected. Sun (Oracle) also (apparently) says at http://java.sun.com/javase/6/webnotes/6u20.html that it has fixed this bug. So is it OK to use version _20 or not?
Comment 28 Matthias Versen [:Matti] 2010-04-17 07:24:07 PDT
You can go to Tools/Addons/plugins and disable the plugin manually.
Shriramana Sharma: read comment #20
Comment 29 Ryan 2010-04-17 07:28:11 PDT
Where abouts can i find these "npdeploytk.dll" files?
Comment 30 dnzldsouza2031@gmail.com 2010-04-17 08:51:42 PDT
hey i am firefox user and it started workin slow now...what should i do???
Comment 31 pingaspingaspingas 2010-04-17 09:06:35 PDT
You are a bunch of elitist ****. Go drive a car made of ****.

Love,

AJ
Comment 32 Alan Baxter 2010-04-17 11:01:49 PDT
Java 6U20 installed Java Deployment Toolkit 6.0.200.2, which is newer than 6.0.200.0.  The current blocklist does not block it.

That said, I don't see any evidence that the current version should be blocked anyhow: Oracle says it's fixed, US-Cert says it's fixed, and the report in http://www.h-online.com/open/news/item/Java-vulnerability-when-lyric-sites-attack-978283.html may be just be a warning about the incomplete Java update process, not the updated plugin.  I see no need to disable Java Deployment Toolkit 6.0.200.2, manually or otherwise.

This note seems to say a problem is caused by the Java update process, rather than the 1.6.0_20 version of the plugin.  I don't see any evidence that the 1.6.0_20 version is problematic.
[url=http://www.kb.cert.org/vuls/id/886582]US-CERT Vulnerability Note VU#886582[/url]
[quote]Note: The installer for Java 1.6.0_20 may not correctly update all instances of the Java Deployment Toolkit plugin. In some cases, the plugin that resides in the \bin\new_plugin directory may not be updated to the fixed 6.0.200.2 version of npdeployJava1.dll. If the new_plugin directory contains npdeploytk.dll version 6.0.190.4 or earlier, then browsers that use plug-ins, such as Mozilla Firefox or Google Chrome, may still be vulnerable. To correct this situation, delete the vulnerable npdeploytk.dll from the new_plugin directory and replace it with the npdeployJava1.dll version from the bin directory.

Please note that the Java Development Toolkit can be installed in multiple browsers, therefore workarounds need to be applied to all browsers with the Java Development Toolkit.[/quote]
Comment 33 firefoxisbraindead 2010-04-17 12:51:51 PDT
I agree with AJ. This is my first experience with this "feature" where you autocratic fuckwits decide to turn off my software running on my computer. Go **** yourselves.
Comment 34 stecklars 2010-04-17 13:35:16 PDT
Got the message 5 minutes ago. Any way to bypass it?
Comment 35 snkhuong 2010-04-17 14:01:10 PDT
I found out there is a trojan called Java/Classloader.T which may relate to this bug. The location of the file infected is :C:\Users\DELL\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\16\2e7afc10-67a0cfc5
file:C:\Users\DELL\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\16\2e7afc10-67a0cfc5->AppletX.class
Comment 36 Daniel Veditz [:dveditz] 2010-04-17 14:22:23 PDT
(In reply to comment #23)
> FYI, block was:
>   <pluginItem>
>     <match name="name" exp="[0-6]\.0\.[01]\d{2}\.\d+"/>
>     <match name="filename" exp="npdeploytk.dll"/>
>   </pluginItem>

Shouldn't we have used severity=1? That way people who's work networks require this and who believe their IDS/Firewall will protect them can turn it back on without disabling the entire blocklist feature.
Comment 37 David Balažic 2010-04-17 15:06:20 PDT
I updated Java to u20 and now Firefox (v3.6.3 / Win XP) shows in Add-ons / Plugins
two "Java Deployment Toolkit" plugins, one v 6.0.190.4 , disabled and one 6.0.200.2 , enabled. Shouldn't the old entry disappear? I only have one npdeploytk.dll file on the system.
Comment 38 Pete 2010-04-17 17:19:24 PDT
Created attachment 439736 [details] [diff] [review]
Java

Cannot install Java. It keeps getting the Error message 1606. When I attempt to install, after the installer stops and then says, "Error 1606. Could not access network location %APPDATA%\.

Thank you!
Pete Moser
Petem011@att.net
Comment 39 Alice Wyman 2010-04-17 17:29:50 PDT
(In reply to comment #37)
> I updated Java to u20 and now Firefox (v3.6.3 / Win XP) shows in Add-ons /
> Plugins
> two "Java Deployment Toolkit" plugins, one v 6.0.190.4 , disabled and one
> 6.0.200.2 , enabled. Shouldn't the old entry disappear? I only have one
> npdeploytk.dll file on the system.

Updating to Java6 u20 should have removed the vulnerable npdeploytk.dll file(s)
but sometimes it doesn't, as mentioned in the "Solution" section of
http://www.kb.cert.org/vuls/id/886582 (see comment 26 and comment 32 above for
more information).
Comment 40 Mike Beltzner [:beltzner, not reading bugmail] 2010-04-19 08:05:19 PDT
Those who are outraged that we have kept an actively exploited plugin from ushering whatever malicious software the web can dream up onto their computers are free to update Java (for free!) from www.java.com or http://java.sun.com/javase/downloads/index.jsp

Dan: I think we'd rather encourage people to get the updated version of the plugin, no? I'm fine for switching it to severity=1 if we believe that the cure is worse than the disease, but as described, this is a pretty big hole
Comment 41 Daniel Veditz [:dveditz] 2010-04-19 13:51:29 PDT
yes, now that a fix is released that's an option.
Comment 42 Shamil 2010-04-19 18:03:51 PDT
Hi,
I am new here. I have done what Comment 32 has told me but do I copy the npdeployJava1.dll to the new_plugin directory or do I move the dll from the bin directory to the new_plugin directory? Please let me know. Also when I checked in my firefox add-ons I see that Java deployment toolkit 6.0.190.4 is still there. I thought it would dissapear because of the update but it didn't? Do I need to worry about that, it is disabled as well and the new updated one is obviously enabled.
Comment 43 Shamil 2010-04-19 18:59:52 PDT
Okay so for some reason the old toolkit dissapeared now so that's good. Now I  moved the dll from the bin directory to the new_plugin directory (npdeployJava1.dll) and deleted npdeployk.dll. Let me know if I did this correctly because I do not know whether to move it or to copy and paste it. And now my last problem is that I update my EI java 64-bit aswell. I saw that after I update the npdeployk.dll got updated to npdeployJava1.dll but it always remained in the bin directory even before the update. Comment 32 tells me to replace the npdeloyk.dll by npdeployJava1.dll and put in the new_plugins directory but there is no more npdeployk.dll and the only files in the new_plugin director is the msvcrt.dll and the npjp2.dll even before the update. So Do I leave everything or do I move the npdeployJava1.dll to the new_plugin directory? Please let me know.
Thanks,
Comment 44 lluscher 2010-04-19 19:34:20 PDT
Sounds like I should uninstall jdk 1.6.0_17 before downloading jdk 6.0.200.2. Will this be enough? Or do I have to scour my registry as well? I'm tired of having to clean up after incomplete uninstalls.
Comment 45 Nathaniel Higgins 2010-04-20 02:29:59 PDT
Okay, So Dumb it down for me, What do i need to do plain and simple to fix this?
Comment 46 Michael Lefevre 2010-04-20 05:03:49 PDT
(In reply to comment #45)
> Okay, So Dumb it down for me, What do i need to do plain and simple to fix
> this?

If you have made it to here, the bad version will have been disabled, so you're safe.  To get the newer version (if you don't already have it), you can go to http://www.java.com and download and install it from there.

Normally I would say that this isn't the right place for support questions, but the Firefox UI directs people to an unhelpful page with no explanation other than a link to this bug in bugzilla.  I would think it would be better to direct people to something more helpful, like a support page, wouldn't it?
Comment 47 Andreas Eibach 2010-04-20 09:59:44 PDT
I fully agree with Michael. A support page would really come in handy.

Besides, I'm finished upgrading to U20 now. (Thanks everybody for the lively participation).
Just for the fun of it, I wanted to retest with Ormandy's test case here:

http://lock.cmpxchg8b.com/bb5eafbc6c6e67e11c4afc88b4e1dd22/testcase.html

Now I get "You need to install additional plugins to view everything on this web site".
???
That's barely logical. I have JRE (U20) plus Java Deployment Toolkit, both 6.0.200.2, so I actually should have all the "plug-ins" needed.
Comment 48 Andreas Eibach 2010-04-20 10:18:24 PDT
UPDATE: Despite the confusing "error message", on PCs with Java 1.6 <= U19, the calc.exe will auto-open anyway.
Comment 49 Rob Hayden 2010-04-20 12:29:14 PDT
I thought this was handled very well, not sure why the hate. I got the option to risk it anyway by unchecking the Disable option (this is on 3.6.3/Win32)

A quick manual update to JRE 6U20 and everything is working fine (Note to Sun/Oracle: defaulting to once-per-month Update checks really isn't often enough)

I expect our corporate IT will catch up shortly and push out the update. In the meantime, the firefox automatic disable may well save some pain.
Comment 50 Phil Carter 2010-04-21 04:13:45 PDT
I agree with Rob, well handled. Probably the only thing could have down different was to have the aforementioned support page.

It highlighted the fact that my lovely Java install was not up-to-date even though I had installed update 20. Ended up uninstalling Java and installing update 20.

Thanks guys.
Comment 51 [:Cww] 2010-04-21 11:13:18 PDT
Support page is here: https://support.mozilla.com/en-US/kb/Java+Deployment+Toolkit+Blocked
Comment 52 Michael Lefevre 2010-04-21 11:24:36 PDT
(In reply to comment #51)
> Support page is here:
> https://support.mozilla.com/en-US/kb/Java+Deployment+Toolkit+Blocked

Good to have it, but it would be better to have it linked up (currently the UI links to https://www.mozilla.com/en-US/blocklist/ , which links to bugzilla bugs). I'd file a bug on improving that if I had any idea where to file it.

(It would be even better if the link from the UI could go straight to the appropriate information for the specific plugin rather than the user having to remember which one it was and then pick it out of a list, but that's not going to be simple...)
Comment 53 Richard 2010-04-21 13:09:05 PDT
As comment 50 it has blocked 1.6 U20 on Linux! Trying to sort
it out
Comment 54 [:Cww] 2010-04-21 14:47:01 PDT
Just found: http://lifehacker.com/5513669/javara-updates-and-removes-old-and-redundant-java-versions for getting rid of any old Java versions floating around that previous installers may have missed.
Comment 55 mike 2010-04-21 20:06:17 PDT
Got the panel to disable Java and restart. BUT I had the latest Java 20 ! Clicked on "get more info".  The restart window disappeared in the background and was inaccessible.  Had to manually exit firefox without being able to continue to read the disable panel.  Java told me I had the latest version !
Comment 56 Junior 2010-04-26 23:15:41 PDT
Mozilla guys, great blog, have disabled JDK plugin .190.4 in my Ffx 3.6.3.  
   For the Bugzilla and Mozilla teams, please update your Plugin Check page, https://www.mozilla.com/en-US/plugincheck/, because the current page (at 04/27/2010-12:55a.m. CDT) still shows JDK 6.0.190.4 in the column under the statement, "The plugins listed below are up to date"  Based on the comments of the experts above, this is Wrong, isn't it? 
   Thanks again.
Comment 57 Junior 2010-04-26 23:45:09 PDT
Also, it is noted that the Java(TM) Platform SE 6 U19 6.0.190.4 is listed as up-to-date in the Plugin Check page, and this has the green button with the words "Up to Date" as well. (The JDK line had the grayed button beside the words, "Unable to detect plugin version.") It would appear that the up-to-date version of each plugin would be the 6.0.200.2.
Comment 58 murdock 2010-04-30 22:18:44 PDT
Created attachment 442893 [details] [diff] [review]
java deployment toolkit 6.0.180.7
Comment 59 Rob 2010-05-03 07:25:15 PDT
(In reply to comment #32)
> Java 6U20 installed Java Deployment Toolkit 6.0.200.2, which is newer than
> 6.0.200.0.  The current blocklist does not block it.
> 
> That said, I don't see any evidence that the current version should be blocked
> anyhow: Oracle says it's fixed, US-Cert says it's fixed, and the report ...
> ...
> This note seems to say a problem is caused by the Java update process, rather
> than the 1.6.0_20 version of the plugin.  I don't see any evidence that the
> 1.6.0_20 version is problematic. ...
> ...

> such as Mozilla Firefox or Google Chrome, may still be vulnerable. To correct
> this situation, delete the vulnerable npdeploytk.dll from the new_plugin
> directory and replace it with the npdeployJava1.dll version from the bin
> directory.
> ...

Your comment and a few others prompted me to check my own situation:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729)


Since I have Cygwin I will use it's "locate" command to find the files:

$ locate npdeploy
locate: warning: database `/var/locatedb' is more than 8 days old (actual age is 10.5 days)
/cygdrive/c/Program Files/Java/jdk1.6.0_14/jre/bin/npdeploytk.dll
/cygdrive/c/Program Files/Java/jdk1.6.0_17/jre/bin/npdeploytk.dll
/cygdrive/c/Program Files/Java/jre1.6.0_13/bin/new_plugin/npdeploytk.dll
/cygdrive/c/Program Files/Java/jre1.6.0_13/bin/npdeploytk.dll
/cygdrive/c/Program Files/Java/jre1.6.0_18/bin/new_plugin/npdeploytk.dll
/cygdrive/c/Program Files/Java/jre1.6.0_18/bin/npdeploytk.dll
/cygdrive/c/Program Files/Java/jre6/bin/new_plugin/npdeploytk.dll
/cygdrive/c/Program Files/Java/jre6/bin/npdeployJava1.dll
/cygdrive/c/Program Files/Mozilla Firefox/plugins/npdeploytk.dll
/cygdrive/c/Program Files/Namoroka/plugins/npdeploytk.dll


$ ls -lrtA /cygdrive/c/Program\ Files/Java/jre6/bin/new_plugin/
total 808
----rwx---+ 1 HP_Administrator SYSTEM 348160 Apr  1 15:55 msvcr71.dll
----rwx---+ 1 HP_Administrator SYSTEM 411368 Apr  1 15:55 npdeploytk.dll
----rwx---+ 1 HP_Administrator SYSTEM  65536 Apr 12 17:29 npjp2.dll

$ ls -l /cygdrive/c/Program\ Files/Java/jre6/bin/npdeployJava1.dll
----rwx---+ 1 HP_Administrator SYSTEM    411368 Apr 12 17:29 npdeployJava1.dll

$ ls -lrtA /cygdrive/c/Program\ Files/Mozilla\ Firefox/plugins/npdeploytk.dll /cygdrive/c/Program\ Files/Namoroka/plugins/npdeploytk.dll
-rwx------+ 1 HP_Administrator None 411368 Nov 17 06:24 /cygdrive/c/Program Files/Namoroka/plugins/npdeploytk.dll
-rwxrwxrwx+ 1 HP_Administrator None 411368 Nov 17 06:24 /cygdrive/c/Program Files/Mozilla Firefox/plugins/npdeploytk.dll


When I compared the versions of:
/cygdrive/c/Program Files/Mozilla Firefox/plugins/npdeploytk.dll
/cygdrive/c/Program Files/Namoroka/plugins/npdeploytk.dll
/cygdrive/c/Program Files/Java/jre6/bin/new_plugin/npdeploytk.dll
/cygdrive/c/Program Files/Java/jre6/bin/npdeployJava1.dll

first I notice that we have files dated April 1, 12 (2010), and Nov 17 2009 and also that the versions are different.

On the Plug-in Check page I have this:
https://www.mozilla.com/en-US/plugincheck/
Java Deployment Toolkit 6.0.190.4
Java Deployment Toolkit 6.0.200.2

and checking my [Tools][Add-ons] I see that I also have "Java Deployment Toolkit 6.0.170.4" which is disabled (I don't know where it found that nor does the add-ons page provide a Path).

I found JavaRa in comment #54 helpful as is comment #32 in trying to update these files.

I notice that this is closed as "Resolved Fixed", I have FF 3.6.3 (nightly) running on WinXP; I don't know that this is "Fixed", I think some of the "fixing" needs to be done by the people at Sun and that _we_ need to test more carefully for "broken-ness".

If there were complicated (Java installed incorrectly?) problem that could be checked (such as this issue) and the user could get a pop-up with a "Details" link which goes to a Webpage to help perform some self diagnosis / repair that would be a useful feature for Firefox.

Rob

Note You need to log in before you can comment on or make changes to this bug.