Closed Bug 739955 Opened 14 years ago Closed 14 years ago

[Windows] Blocklist vulnerable jre versions pre update 31 due to security issue

Categories

(Toolkit :: Blocklist Policy Requests, defect)

Product:
Toolkit
Component:
Blocklist Policy Requests
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: cbook, Assigned: jorgev)

References

Details

(Whiteboard: [plugin][softblock][windows only] READ COMMENT 91 BEFORE POSTING)

see http://blogs.technet.com/b/mmpc/archive/2012/03/20/an-interesting-case-of-jre-sandbox-breach-cve-2012-0507.aspx and our own http://krebsonsecurity.com/2012/03/new-java-attack-rolled-into-exploit-packs/ we should blocklist finally the older jre versions to keep our users safe on the web. Its fixed in update 30 but latest version is update 31. so i'm fine either way we block. Let me know what information is also needed to block.
This issue is highly critical, as the Blackhole Exploit Kit is very widespread and the vulnerability is reliably exploitable.
and since we are at it, JDK and JRE 7 Update 2 and earlier is affected too according to http://www.oracle.com/technetwork/topics/security/javacpufeb2012-366318.html
Email sent to the Java team advising them of this bug, and asking for clarification of versions affected by CVE-2012-0507
Lets block this thing.
Let's go ahead and stage a soft block. Jorge, can you take this? Kev/Tomcat, do you know details of the plugin filenames? Are they the same as from bug 689661 comment #47 ?
Assignee: nobody → jorge
Whiteboard: [plugin][softblock][needs staging]
They should be the same as earlier. Block should affect versions below 1.6.0.31.
Is the plugin version number the same for all platforms?
The block has been staged: https://addons-dev.allizom.org/en-US/firefox/blocked/p75 It blocks versions under 1.6.0.31 for all platforms. We need QA to verify that versions below 1.6.0.31 are softblocked and others aren't.
Whiteboard: [plugin][softblock][needs staging] → [plugin][softblock]
Keywords: qawanted
Summary: Blocklist vunerable jre versions pre update 31 due security issue → Blocklist vulnerable jre versions pre update 31 due to security issue
(In reply to Jorge Villalobos [:jorgev] from comment #7) > Is the plugin version number the same for all platforms? It should be. Sometimes Linux only gives three significant digits in version numbers, which makes it fun depending on how we do the lookup/parse versions, but the same versioning applies to all platforms w/Java.
Firefox 12b2 Windows XP: 1) Delete blocklist.xml from profile 2) Change extensions.blocklist.url to use addons-dev.allizom.org 3) Execute Components.classes["@mozilla.org/extensions/blocklist;1"].getService(Components.interfaces.nsITimerCallback).notify(null); in Error Console 4) Install JRE 1.6.0.26, allow installation of JavaConsole 6.0.26 5) Run Java verification: http://www.java.com/en/download/installed.jsp > Java started and notified me that an update was available Did I do something wrong?
I also got same behavior on Windows 7 64-bit as comment 10 with JRE 1.6.0.29 on Firefox 13 Aurora.
Testing on Mac 10.6 using a machine that has Java 1.6.0.29, I can see the blocklist in the blocklist.xml file but Java does not seem to be softblocked according to https://wiki.mozilla.org/images/f/fc/Pluginblock.png.
Windows lists the version as v6. Java(TM) Platform SE 6 U27 File: npjp2.dll Version: 6.0.270.7 Next Generation Java Plug-in 1.6.0_27 for Mozilla browsers
Verified blocklist working on Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120328 Firefox/14.0a1 Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120328 Firefox/13.0a2 Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0 Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0 and Java 1.6.0_30
I did the steps in comment #10 with winxp, FF 10.0.3 and java 1.6.0.27 and have similar results. about:addons doesn't shows java enabled; the download/installed.jsp url starts java and offers an update to Version 6 Update 31.
I just moved the regex from the name field to the description where I think the version we want to match is. If it failed for you, can you try again?
After comment #16, I retried comment #10 with winxp, ff 10.0.3, java 1.6.0.27, and I can see the change to use '<match name="description" ..' in blocklist.xml, I get the warning dialog, and after taking the restart, about:addons shows java disabled. http://www.java.com/en/download/installed.jsp asks if I want to install java; other java sites report the plugin is disabled.
Great, sorry about the problem before. Kevin, would you also be able to re-test to make sure we didn't regress Linux by switching to description? Thanks!
the information for mac is: Java Applet Plug-in File: JavaAppletPlugin.plugin Version: 14.1.0 Displays Java applet content, or a placeholder if Java is not installed. MIME Type Description Suffixes application/x-java-applet;version=1.1.3 Java applet application/x-java-applet Basic Java Applets javaapplet application/x-java-applet;version=1.2.2 Java applet application/x-java-applet;version=1.5 Java applet application/x-java-vm Java applet application/x-java-applet;version=1.3.1 Java applet application/x-java-applet;version=1.3 Java applet application/x-java-applet;version=1.1.2 Java applet application/x-java-applet;version=1.1 Java applet application/x-java-applet;version=1.2.1 Java applet application/x-java-applet;version=1.6 Java applet application/x-java-applet;version=1.4.2 Java applet application/x-java-applet;version=1.4 Java applet application/x-java-applet;version=1.1.1 Java applet application/x-java-applet;version=1.2 Java applet application/x-java-applet;jpi-version=1.6.0_29 Java applet
The version for Mac is different on my 10.6 machine: 13.6.0. It is likely different on 10.5 as well but I will have to check on the lab machine.
The version on my OS 10.5 is 1.6.0.26
(In reply to Bob Clary [:bc:] from comment #21) > The version on my OS 10.5 is 1.6.0.26 Can you please post the full description from about:plugins? Can someone confirm that the block still works on Linux?
Java Plug-In 2 for NPAPI Browsers File: JavaPlugin2_NPAPI.plugin Version: 12.9.0 Java Plug-In 2 for NPAPI Browsers
Depends on: 740544
(In reply to Jorge Villalobos [:jorgev] from comment #22) > Can someone confirm that the block still works on Linux? kbrosnan, can you please retest this?
From 10.6: Java Plug-In 2 for NPAPI Browsers File: JavaPlugin2_NPAPI.plugin Version: 13.6.0 Java Plug-In 2 for NPAPI Browsers MIME Type Description Suffixes application/x-java-applet;version=1.1.3 Java applet application/x-java-applet Basic Java Applets javaapplet application/x-java-applet;version=1.2.2 Java applet application/x-java-applet;version=1.5 Java applet application/x-java-vm Java applet application/x-java-applet;version=1.3.1 Java applet application/x-java-applet;version=1.3 Java applet application/x-java-applet;version=1.1.2 Java applet application/x-java-applet;version=1.1 Java applet application/x-java-applet;version=1.2.1 Java applet application/x-java-applet;version=1.6 Java applet application/x-java-applet;version=1.4.2 Java applet application/x-java-applet;version=1.4 Java applet application/x-java-applet;version=1.1.1 Java applet application/x-java-applet;version=1.2 Java applet application/x-java-applet;jpi-version=1.6.0_29 Java applet
This is what I see on 10.6: Java Applet Plug-in File: JavaAppletPlugin.plugin Version: 14.0.3 Displays Java applet content, or a placeholder if Java is not installed. MIME Type Description Suffixes application/x-java-applet;jpi-version=1.6.0_24 Java applet application/x-java-applet;version=1.1.3 Java applet application/x-java-applet Basic Java Applets javaapplet application/x-java-applet;version=1.2.2 Java applet application/x-java-applet;version=1.5 Java applet application/x-java-vm Java applet application/x-java-applet;version=1.3.1 Java applet application/x-java-applet;version=1.3 Java applet application/x-java-applet;version=1.1.2 Java applet application/x-java-applet;version=1.1 Java applet application/x-java-applet;version=1.2.1 Java applet application/x-java-applet;version=1.6 Java applet application/x-java-applet;version=1.4.2 Java applet application/x-java-applet;version=1.4 Java applet application/x-java-applet;version=1.1.1 Java applet application/x-java-applet;version=1.2 Java applet
more complete output on 10.5 Java Plug-In 2 for NPAPI Browsers File: JavaPlugin2_NPAPI.plugin Version: 12.9.0 Java Plug-In 2 for NPAPI Browsers MIME Type Description Suffixes application/x-java-applet;version=1.3 Java applet application/x-java-applet;version=1.5 Java applet application/x-java-applet;version=1.1.3 Java applet application/x-java-applet;version=1.2 Java applet application/x-java-applet;version=1.2.1 Java applet application/x-java-applet;version=1.4.2 Java applet application/x-java-applet;version=1.1 Java applet application/x-java-applet;version=1.1.1 Java applet application/x-java-applet;version=1.3.1 Java applet application/x-java-applet;version=1.6 Java applet application/x-java-applet Basic Java Applets javaapplet application/x-java-applet;jpi-version=1.6.0_26 Java applet application/x-java-vm Java applet application/x-java-applet;version=1.4 Java applet application/x-java-applet;version=1.1.2 Java applet application/x-java-applet;version=1.2.2 Java applet
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #24) > (In reply to Jorge Villalobos [:jorgev] from comment #22) > > Can someone confirm that the block still works on Linux? > > kbrosnan, can you please retest this? I can't get this block to work today. Doing the same steps I took last night. Would like confirmation of this.
addons-dev seems to be experiencing problems at the moment.
It's back up now, can you please try again?
This appears to be broken on Linux. Java(TM) Plug-in 1.6.0_30 File: libnpjp2.so Version: The next generation Java plug-in for Mozilla browsers. MIME Type Description Suffixes application/x-java-vm Java™ Plug-in application/x-java-applet Java™ Plug-in Applet application/x-java-applet;version=1.1 Java™ Plug-in application/x-java-applet;version=1.1.1 Java™ Plug-in application/x-java-applet;version=1.1.2 Java™ Plug-in application/x-java-applet;version=1.1.3 Java™ Plug-in application/x-java-applet;version=1.2 Java™ Plug-in application/x-java-applet;version=1.2.1 Java™ Plug-in application/x-java-applet;version=1.2.2 Java™ Plug-in application/x-java-applet;version=1.3 Java™ Plug-in application/x-java-applet;version=1.3.1 Java™ Plug-in application/x-java-applet;version=1.4 Java™ Plug-in application/x-java-applet;version=1.4.1 Java™ Plug-in application/x-java-applet;version=1.4.2 Java™ Plug-in application/x-java-applet;version=1.5 Java™ Plug-in application/x-java-applet;version=1.6 Java™ Plug-in application/x-java-applet;jpi-version=1.6.0_30 Java™ Plug-in application/x-java-bean Java™ Plug-in JavaBeans application/x-java-bean;version=1.1 Java™ Plug-in application/x-java-bean;version=1.1.1 Java™ Plug-in application/x-java-bean;version=1.1.2 Java™ Plug-in application/x-java-bean;version=1.1.3 Java™ Plug-in application/x-java-bean;version=1.2 Java™ Plug-in application/x-java-bean;version=1.2.1 Java™ Plug-in application/x-java-bean;version=1.2.2 Java™ Plug-in application/x-java-bean;version=1.3 Java™ Plug-in application/x-java-bean;version=1.3.1 Java™ Plug-in application/x-java-bean;version=1.4 Java™ Plug-in application/x-java-bean;version=1.4.1 Java™ Plug-in application/x-java-bean;version=1.4.2 Java™ Plug-in application/x-java-bean;version=1.5 Java™ Plug-in application/x-java-bean;version=1.6 Java™ Plug-in application/x-java-bean;jpi-version=1.6.0_30 Java™ Plug-in
I tried again on Mac 10.6 using Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20100101 Firefox/12.0 and I get the same results as in Comment 12.
We made some changes in the regular expression, so we need to test the staged block again on all platforms. The block should work on all versions lower than 1.6.0_31 and all versions between and including 1.7.0 and 1.7.0_2. Anthony et al. can you please test the block again?
I tested the new blocklist again on Mac 10.6.8 and 10.7.4 I need to do more testing since I am seeing a new issue on 10.7.4 using nightly where it is hanging on java sites and I have to force quit the browser each time. When I tested on the same 10.6.8 machine, deleted the blocklist.xml file, and pinged again Java is still not being blocklisted. I was testing that scenario with the latest beta release. Jorge: Is the block still https://addons-dev.allizom.org/en-US/firefox/blocked/p75 or did the number change when you changed the regular expression?
(In reply to Marcia Knous [:marcia] from comment #34) > Jorge: Is the block still > https://addons-dev.allizom.org/en-US/firefox/blocked/p75 or did the number > change when you changed the regular expression? It changed to this: https://addons-dev.allizom.org/en-US/firefox/blocked/p58
With Firefox Aurora 13.0a2 on Windows 7: 1) Install JRE 6.0.29 2) Set extensions.blocklist.url from addons.mozilla.org to addons-dev.allizom.org 3) Quit Firefox and ensure no blocklist.xml in profile folder 4) Start Firefox and force blocklist ping through error console -> Dialog stating "Aurora has determined that the following add-ons are known to cause stability or security problems" with "Disabled" checked 5) Leave "Disabled" checked and Restart Firefox about:plugins ------------- Java Deployment Toolkit 6.0.290.11 File: npdeployJava1.dll Version: 6.0.290.11 NPRuntime Script Plug-in Library for Java(TM) Deploy MIME Type: application/java-deployment-toolkit Description: Suffixes: about:addons ------------ Java Development Toolkit 6.0.290.11 (enabled) Java(TM) Platform SE 6u29 6.0.290.11 (disabled)
Justin, Jorge: I'm starting to get a little lost in this bug. It's not clear to me that this is fixed or if it's been tested sufficiently. If recent comments don't prove this fixed I would like to suggest that we take testing this offline into a focused testplan which QA can execute on over the next couple of days and then report back here once complete.
We need this tested on all 3 major platforms. We've had some problems where the addons-dev site was reset and the blocklist entry was lost, and then we had to update the regular expression to take into account the 1.7.0 branch of the JRE. The block is now staged again: https://addons-dev.allizom.org/en-US/firefox/blocked/p80. This block should work correctly on Windows and Linux, and it is unclear if it works for all Mac OS systems. Can we get these test results in today?
(In reply to Jorge Villalobos [:jorgev] from comment #38) > Can we get these test results in today? Marcia is putting together a mini test plan right now. We'll try to get this done and tested today.
We've been doing some testing and are getting mixed results. Can someone please clarify that the following is expected. Using Win7 64-bit and JRE 6u27: * force ping prompts me to disable, and I restart Firefox * about:plugins shows JRE 6u27 enabled * about:addons shows JRE 6u27 disabled, JDK 6u27 enabled, and JavaConsole 6u27 enabled * blocklist.xml does not contain an addons-dev URL * going to http://www.w3.org/People/mimasa/test/object/java/clock displays 4 applets stating "plugin disabled"
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #40) > * about:plugins shows JRE 6u27 enabled Sounds like a bug in about:plugins, but it shouldn't block this bug. > * about:addons shows JRE 6u27 disabled, JDK 6u27 enabled, and JavaConsole > 6u27 enabled We're only blocking the JRE plugin. The others aren't a security risk AFAIK. > * blocklist.xml does not contain an addons-dev URL Blocklist entries in blocklist.xml have a block ID, like <pluginItem blockID="p80">. That's how the URL is generated. For the link to work, you also need to change the extensions.blocklist.itemURL preference. > * going to http://www.w3.org/People/mimasa/test/object/java/clock displays > 4 applets stating "plugin disabled" Good!
Java Console being enabled is fine, but the JDK 6u27 being enabled concerns me a little. Gonna take a quick peek, but the "plugin disabled" below is promising.
(In reply to Jorge Villalobos [:jorgev] from comment #41) > > * blocklist.xml does not contain an addons-dev URL > Blocklist entries in blocklist.xml have a block ID, like <pluginItem > blockID="p80">. That's how the URL is generated. For the link to work, you > also need to change the extensions.blocklist.itemURL preference. Adding this to the process correctly fixes the problem I reported in comment 40 wrt blocklist.xml and JavaConsole. JDK still enabled but plugin content is blocked from executing. Note that updating to JRE 6u31 after the block is enabled does not unblock. Is this expected or is it up to the user to re-enable the plugin once updated?
I think we're good to go with the JDK stuff, but the enable comment is something we need an answer on; will it require a restart for Firefox post-install?
Test results are being added to https://etherpad.mozilla.org/Java-Testing. There are some open questions as I am testing Mac.
(In reply to Kev [:kev] Needham from comment #44) > I think we're good to go with the JDK stuff, but the enable comment is > something we need an answer on; will it require a restart for Firefox > post-install? After updating to JRE 6u31 and restarting Firefox, here is about:addons|Plugins says: > Java (TM) Platform SE 6 U31 6.0.310.5 is known to cause security problems or stability issues > Java (TM) Platform SE 6 U31 6.0.310.5 (disabled) Enabling does not require restart.
ugh. so new naming and versioning convention. that's.... not awesome, but wondering why the 6.0.* gets trapped.
None of those strings appear to be caught by the regular expression. Anthony, can you post the whole plugin description from about:plugins after it is enabled? (no need to post the whole MIME type table)
(In reply to Jorge Villalobos [:jorgev] from comment #48) > None of those strings appear to be caught by the regular expression. > Anthony, can you post the whole plugin description from about:plugins after > it is enabled? (no need to post the whole MIME type table) Java(TM) Platform SE 6 U31 File: npjp2.dll Version: 6.0.310.5 Next Generation Java Plug-in 1.6.0_31 for Mozilla browsers
I just made a minor correction to the block to correct the problem where upgrading to u31 didn't enable the plugin again. Please test again (sorry :\).
(In reply to Jorge Villalobos [:jorgev] from comment #50) > I just made a minor correction to the block to correct the problem where > upgrading to u31 didn't enable the plugin again. > > Please test again (sorry :\). Confirmed. Blocklist still works and the plugin update is enabled by default.
On Ubuntu, I can confirm that the blocklist is correctly installed (re: blocklist.xml) but I'm not sure what version of IcedTea should be blocked. I currently have IcedTea-Web Plugin (using IcedTea-Web 1.1.3 (1.1.3-1ubuntu1.1)) installed and active with the blocklist enabled.
This appears to be failing on Linux, as per kbrosnan's testing in the etherpad: * Using Oracle Java 6u30 * Blocklist is updated correctly * Java Plugin is still enabled From about:plugins: Java(TM) Plug-in 1.6.0_30 File: libnpjp2.so Version: The next generation Java plug-in for Mozilla browsers.
I just made a small correction to address kbrosnan's test. I don't know about IcedTea-Web either, and searching around didn't give me a clear answer.
IcedTea is the open version of "Java 7", i.e. 1.7, FWIW.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #55) > IcedTea is the open version of "Java 7", i.e. 1.7, FWIW. Their wiki seems to say that IcedTea 1.* is based on Java 6 and 2.* is based on Java 7: http://icedtea.classpath.org/wiki/Main_Page
(In reply to Jorge Villalobos [:jorgev] from comment #54) > I just made a small correction to address kbrosnan's test. I'm still seeing what kbrosnan saw in comment 53 (ie. blocklist.xml is updated but the plug-in remains enabled) -- tested on Ubuntu 11.10 64-bit using Oracle Java 1.6.0_30
hey guys, since the most important OS in this case (and exploited OS) is windows and Mac, can we push this to protect the users and take care of ubuntu than?
(In reply to Carsten Book [:Tomcat] from comment #58) > hey guys, since the most important OS in this case (and exploited OS) is > windows and Mac, can we push this to protect the users and take care of > ubuntu than? +1. Of course all systems are vulnerable, but we should not delay a fix for those systems that are attacked in the wild, in favorite for a system that is not. Let's block it on Windows (and Mac if easily possible), and then find the proper solution for Linux.
I'm all for moving on this today. Maybe we can focus on separate entries for the platforms so we can test individually, rather than one entry for all platforms. F-Secure has another article on it being used by a new variant of Flashback now http://www.f-secure.com/weblog/archives/00002341.html, so it'd be great if we can separate them out.
https://etherpad.mozilla.org/Java-Testing shows all versions failed on Mac when I tested on Friday. I think as Kev suggests in Comment 60 that a separate block entry per platform might be a better approach.
We're going ahead with the Windows-only block at this point. I'll clone a bug for figuring out the issues with Mac.
Summary: Blocklist vulnerable jre versions pre update 31 due to security issue → [Windows] Blocklist vulnerable jre versions pre update 31 due to security issue
Whiteboard: [plugin][softblock] → [plugin][softblock][windows only]
Blocks: 741592
The Windows (and Linux, maybe?) block has been pushed live. https://addons.mozilla.org/en-US/firefox/blocked/p80 http://blog.mozilla.com/addons/2012/04/02/blocking-java/
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
To all visitors: please visit http://java.com/ to get an updated version of Java and the plugin.
Hi, I am the maintainer of IcedTea-Web. The fix for this breaks compatibility between Firefox and IcedTea-Web as the plug-in is now blocked by Firefox. This means that the default Java plug-in shipped with Ubuntu, Fedora, and other distros is now disabled. IcedTea-Web uses IcedTea/OpenJDK for its JRE. With v7, the update numbers between proprietary JDK and OpenJDK are in synch. so a check for version will work. However with 6, the OpenJDK update number is lower than that of a proprietary JDK. This does not indicate a vulnerable version. Please see this for more info: http://dbhole.wordpress.com/2011/05/27/why-do-xx-and-yy-in-jdk6-uxx-and-openjdk-byy-differ/ I think that for IcedTea-Web, comparing to JRE version only is incorrect regardless. IcedTea-Web is developed independently of OpenJDK, and has its own versioning scheme. A more secure comparison would be to check for IcedTea-Web version AND underlying JRE version as both may vary independently and present potential vectors for attack. Please let me know if you need any further input -- I'd be happy to provide any help needed from our side to get this fixed asap.
I've updated the block to remove the Iced Tea plugin for now. Can you give us the Iced Tea versions that correspond to JRE versions below 1.6.0_31 or between 1.7.0 and 1.7.0_2? Note that we're doing regexp matching against the plugin description, so this is dependent on the description text.
Hi, I am a member of the Ubuntu Security Team, In addition to what Deepak said about IcedTea-Web and the different versioning between the OpenJDK JRE and the proprietary Oracle JRE, please note that Linux distribution vendors often address security issues by backporting fixes to earlier version, not by updating to an entirely new version. This means that simple major version number tests will not be accurate in identifying whether a given piece of software is vulnerable to a specific issue or not. Ubuntu addressed this specific issue for OpenJDK on February 24th in USN-1371-1 http://www.ubuntu.com/usn/usn-1373-1/ ; similarly, Red Hat addressed it in https://rhn.redhat.com/errata/RHSA-2012-0135.html and Debian in http://www.debian.org/security/2012/dsa-2420 . Examining the versions involved should give you some idea of the difficulty in attempting to blacklist based on version numbers. Relying on version numbers alone will result in Linux users getting java plugins blacklisted even though the vulnerability has been fixed. (This particular issue is all the more confusing because Oracle initially mis-identified the flaw as CVE-2011-3571, and later updated the identifier to the (correct) CVE-2012-0507.)
Thanks! The plug-in versions do not correspond to any specific JRE version. Currently we have 2 latest releases, 1.1.5 and 1.2. Either version can be build with any JRE 6 or 7 (probably even 8). The only limitation is that at-least JRE 6 is required. If you want to check only the plug-in version, checking to ensure "1.1.5" or "1.2" would be best. The string looks like this: "IcedTea-Web Plugin (using IcedTea-Web 1.2 (fedora-1.fc16-x86_64))" So checking for "using IcedTea-Web <versionstring>" should be fine IMO. Please note that this will not check for underlying VM, but that is not exposed via the description text any way.
Hi! I'm part of a IT team, and we have a big problem: we have developed a web application using Applets and working on Firefox for the government, we have 15.000 users using this application that probably won't can work tomorrow. The version of our Firefox is 3.0.10 and java 1.6.0.13, and now this application only runs with these versions. Then, is there any solution to fix this problem keeping versions of Firefox and Java? Firefox has updated the blocklist with java plugin, is there some way to disable the blocklist update (setting windows registry or something...)?? Any suggestions? Thanks!
You can disable the blocklist (via the about:config preference extensions.blocklist.enabled, I believe). Note that if you're using Firefox 3.0.10 to browse the public Internet it has been unsupported for a very long time and is full of all sorts of security bugs ...
cgomez and others: This is a softblock, meaning that you can ignore the warnings and continue using the plugin normally. There's no need to disable the blocklist in order to continue using Java. We strongly recommend that you update Java (and Firefox!) as soon as possible, but you should be able to continue using both without any problems.
@Steve Beattie: do you know if there are any plugins being incorrectly blocked, other than Iced Tea? Other than the Windows block, we're blocking libnpjp2.so using the same JRE version ranges.
(In reply to Jorge Villalobos [:jorgev] from comment #71) > cgomez and others: This is a softblock, meaning that you can ignore the > warnings and continue using the plugin normally. Alas, untrue if you are foolish enough to run Firefox 3.0.x--the "soft" block was not introduced until Firefox 3.5. In Firefox 3.0 a block is a block and the <severity> tag is ignored. For the love of God do not use Firefox 3.0.x on any machine connected to the internet!!! There are in-the-wild exploits built into many commercial exploit packs that work against those old versions. Of course Java 1.6.0.13 is an even bigger worry. (In reply to cgomez from comment #69) > The version of our Firefox is 3.0.10 and java 1.6.0.13, and now this > application only runs with these versions. I find that hard to believe. There should be no compatibility problems between Firefox 3.0.10 and the last 3.0.19 version. Not that I recommend ANY version of 3.0 at this date, just saying it doesn't sound like you guys tried very hard. Ditto Sun/Oracle's design for Java 1.6 updates -- you should be able to use the latest 1.6 update, which is not blocked. Unless, of course, your application relies on exploiting one of the security holes that was patched. There is no safe way to run Firefox 3.0.x or old Java versions. You are trading the work/cost of upgrading your application against the potential complete compromise of your business. You must protect those machines from getting near the internet (because even "safe" sites get hacked). Or maybe run those versions only in a virtual machine for the sole purpose of accessing that application and revert the VMs to a restore point regularly.
Need to unblock Java old version my work needs that version
Either open Tools > addons > plugins and click enable on Java or company wide set extensions.blocklist.enabled. Though I don't believe that pref will undo any disabling that has already happened. Either way bugs are not for discussing tangential issues. We have mailing lists/newsgroups for that. https://lists.mozilla.org/listinfo/dev-apps-firefox
The information provided in comment 75 does not work or is incomplete. It is absolutely essential that I get Java Plugin 1.6.0_26 re-enabled as later versions on Java 1.6 (I have tested all up to 1.6.31) do NOT work with some of the web applications in my company. Many of these applications run on devices that can not be updated, so we are stuck with needing to use older Java plugins. If this can not be re-enabled, we shall have to abandon usage of Firefox and revert to using Internet Explorer.
(In reply to Alex Hampson from comment #76) > The information provided in comment 75 does not work or is incomplete. Without specifying what version of Firefox you are using and what happened when you tried the steps above (from comment 75), it is unlikely that someone will be able to help you. Furthermore, please note that this is a soft block that can be bypassed while browsing. Note that there is a mailing list for solving such problems, it shouldn't be done in the bug. You can also find us on IRC (irc.mozilla.org #security).
My thanks to Christian for his observations. I am running the Firefox portable 3.6.28. When I followed Tools > addons > plugins the enable button for the Java plugin was grayed out and the option could not be selected. I had a look at "extensions.blocklist.enabled" under "about:config" and it was not obvious how the particular plugin could be re-enabled. And before anyone suggests using Firefox portable 11.0, that version of Firefox fails at startup on my Windows XP desktop (Phenom II X6 processor). It even fails when using safe-mode to start it. But to get back on topic, how do I re-enable the Java 1.6.26 plugin ? Also, if it is not too much to ask for: How is a soft block bypassed while browsing ?
(In reply to Alex Hampson from comment #78) > I had a look at "extensions.blocklist.enabled" under > "about:config" and it was not obvious how the particular plugin could be > re-enabled. If you set this particular option to "false" (just double clicking on it should do), the blocklisting feature will be entirely disabled. There is no way to restrict this to the particular Java block, all blocks will be affected, no vulnerable plugins will be blocked anymore. > Also, if it is not too much to ask for: How is a soft block bypassed while > browsing ? I don't have the UI here right now (I don't have a Java Web Plugin enabled) but there should be a menu/button to continue anyway.
OK - NORMAL PEOPLE FIX (Just trying to surf web/games) 1. The fix will not involve Mozilla options in any way. 2. On the Java.com website there are instructions for removing older versions of Java SRE from your computer. This is how to remove and fix for WINDOWS other operating system information is on Java.com 3. Go to Control Panel - Programs and Features - Uninstall any versions of Java on your computer - The older versions are causing the problems and if they are not uninstalled you won't be able to use Java because of the block. I had to remove 3. Each version takes a few minutes to remove. 4. Restart mozilla and go to Java.com and install the newest update. You do not need to download Java 7 from oracle. YES this is the same version you just uninstalled. 5. Firefox will restart and you can run a check of your Java SRE on Java.com. At this point your Java should be running fine. ***NOTE - Again it is only a fix for people trying to use the most recent version. While I understand and sympathize with those people/companies who are trying to unblock earlier versions of Java this solution will not help you. It took me over 30 minutes to find out that even though I had the most recent version of Java I was blocked because of the older versions on the computer.
From a Danish perspective, the current block of older versions of Java, without an explanation, is causing problems. All Danish banks are using a Java applet for login. So Java is needed to perform online banking. I would recommend that users get some kind explanation when a plugin is blocked. I am convinced that the Danish banks and the Danish Mozilla support forum would appreciate that. That might also prevent people from ditching Firefox.
There's a link to more information about the block in the warning message that appears to users. That should take you here: https://addons.mozilla.org/firefox/blocked/p80 There are more details in this blog post, also: http://blog.mozilla.com/addons/2012/04/02/blocking-java/
how do i unblock my java? i need it for school
@Jorge Villalobos: I'm not aware of any other incorrect blocks. Blocking libnpjp2.so should be okay as it's the proprietary java plugin and they don't appear interested in shipping a backported version of the fix. Thanks!
(In reply to kbattishill from comment #83) > how do i unblock my java? i need it for school Please follow the instructions at https://bugzilla.mozilla.org/show_bug.cgi?id=739955#c80
re: #82 That link is not very visible. I did not notice it and I am not exactly a beginner. Besides, I have a feeling that even if the Danish Mr. Smith found the link, he will be none the wiser when being led to an English text. We need to make it more clearly what is happening. In the Danish Mozilla support we have already had one user telling us that he dumped Firefox because of this and a supporter from a Danish Bank tried to get help because a lot of their customers no longer can use their online banking. This is not good!
It is not good for people to be running versions of Java so old that malware takes over their computers either, Kim.
(In reply to Christian Holler (:decoder) from comment #77) > (In reply to Alex Hampson from comment #76) > > The information provided in comment 75 does not work or is incomplete. > > Without specifying what version of Firefox you are using and what happened > when you tried the steps above (from comment 75), it is unlikely that > someone will be able to help you. Furthermore, please note that this is a > soft block that can be bypassed while browsing. > > Note that there is a mailing list for solving such problems, it shouldn't be > done in the bug. You can also find us on IRC (irc.mozilla.org #security). Im not looking for help either. What Christian and I would like is for you guys to LISTEN. There are way too many embedded systems that depend on older versions of Java - systems operated by very capable network security teams. Since this is about FIXing something you BROKE on my machine today... I want you to listen. If you insist on not giving end users the option to choose not to block, then you have cost the user community time. I use FireFox to save time... today your group has cost me time. On balance, FF is net positive so Im staying with it. What you guys need to know is that more such behavior (taking choice away and consuming more of end user's time) will cause people to look for alternatives. Thanks to everyone who works hard in the FireFox community - and keep up the good work!
(In reply to Alex Hampson from comment #76) > The information provided in comment 75 does not work or is incomplete. It is > absolutely essential that I get Java Plugin 1.6.0_26 re-enabled as later > versions on Java 1.6 (I have tested all up to 1.6.31) do NOT work with some > of the web applications in my company. Many of these applications run on > devices that can not be updated, so we are stuck with needing to use older > Java plugins. If this can not be re-enabled, we shall have to abandon usage > of Firefox and revert to using Internet Explorer. You have to disable the "extensions.blocklist.enabled" in "about:config" and then delete or edit the blocklist.xml file in your "%APPDATA%\Mozilla\Firefox\Profiles\{your profile}\" directory. If you edit, remove the "p80" block. We now have about 100 training lab machines that have to be updated and re-snapshotted because a small group of people made a bad decision that prevents my students from being able to perform their lab work in a $3000/week training class... not happy with this!
Depends on: 742369
As far as I've heard, something went wrong with the kind of blocking we applied. We intended to block it in a way that lets users override it and still use the insecure, exploitable, vulnerable older Java plugins. Due to some error in our systems a non-overridable block was applied instead and Mozilla people are working on changing that and correctly making it an overridable one.
This is fixed in production now. The block should now work as a softblock. If you had your plugin disabled here's how to re-enable it: 1) Open about:support. 2) Look for the Profile Directory entry and click on the button next to it in order to open it. 3) Look for blocklist.xml and delete it. 4) Open about:addons 5) Enable the plugin again. In a day or so (when the blocklist is reloaded) you'll see a new warning about the plugin (if you're using a vulnerable version), which you should be able to ignore. Even if you accidentally disable it again, you can follow steps 4 and 5 and this should correct the problem permanently. There is no need to change any settings. Changing blocklist preferences can make your system very insecure and we strongly recommend against it.
Keywords: qawanted
Whiteboard: [plugin][softblock][windows only] → [plugin][softblock][windows only] READ COMMENT 91 BEFORE POSTING
> It is not good for people to be running versions of Java so old that malware takes over their computers either, Kim. True, but then tell people that. That is actually all that I/we in MozillaDenmark is asking for. Personally I thought that my Java was updated automatically, and that it is only Microsoft that does not push updates "live". So I thought my Java was up to date. There was nothing in the dialog box that told me I was wrong. And I am an experienced user with an interest in security, how in the world should ordinary users know better? I am sure most supporters in the Danish banks just tell their users to use another browser. And that is what they will do. What the dialog box should do in cases like this is to inform the user that the software is insecure and that there is a new version available. Maybe have three options in the box: 1. Help me upgrade my Java [or whatever program it is]. 2. Turn off Java (this may affect your surfing). 3. I want to continue using the insecure Java. Number 3 is very important for some businesses as it can be seen from the responses in this bug. And it should be possible for administrators in businesses to make that decision and roll it out before the end user is presented for the box.
Jorge, Those instructions fail because the lack of an "enable" button in about:addons persists. Please advise further, thanks.
Matt, you might need to reload Firefox after deleting the file. Let me know if this continues to fail for you.
how can I unsubscribe from Bugzilla? Thank you.
Jorge, this doesn't appear to work the way described. Removing blocklist.xml, reinstalling/upgrading firefox, the addon is still disabled with no enable feature available. With that said, I am not completely blowing up profiles when I do this. But I thought the suggestion here was that that wouldn't be required... not true? Thanks again.
Some people have mentioned that it is also necessary to delete pluginreg.dat from the profile. Can you please try this?
We've moved on to deploying 6-31, after determining our compatibility concerns were much ado, so I'm not likely to have any new information on the effectiveness of that technique. Thanks again for the help today.
Does this also block IBM's Win32 Java plugin too? Presumably it has the same problems. IBM has it's own JRE environment that ships with various Rational and other products, but it's not publicly distributed. On my work machine running Nightly http://hg.mozilla.org/mozilla-central/rev/c410b2d6d570 , I still see the following plugin active: IBM Developer Kit for Windows,Java,1.6.0 File: npjp2.dll Version: 6.0.0.0 Next Generation Java Plug-in 1.6.0 for Mozilla browsers You might be able to score some a sample of the code through the links at http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14029823
Thank you for letting us know. I made a small adjustment to account for this plugin version.
We have a lot of test machines we need to use with Java 14 and 17. Is there anyway to unblock this? We use it at our own risk. It should not be a block but a choice.
In case you're trapping for the Java Deployment Toolkit too, the IBM version on my work system reports itself as: Java Deployment Toolkit 6.0.0-20101101_01 File: npdeployJava1.dll Version: 6.0.0.0 NPRuntime Script Plug-in Library for Java(TM) Deploy
(In reply to German from comment #101) > We have a lot of test machines we need to use with Java 14 and 17. Is there > anyway to unblock this? We use it at our own risk. It should not be a block > but a choice. See http://blog.mozilla.com/addons/2012/04/04/update-on-java-blocklist/ (In reply to Barry Marshall from comment #102) > In case you're trapping for the Java Deployment Toolkit too No, we're not blocking it. Thank you for the information, though.
Depends on: 743446
FYI, the correct way to determine if the installed IBM Java build has the same problem can be found in Bug 743446 Comment #3. Apparently the IBM Java plugin information doesn't change based on the level of the underlying JRE.
It doesn't block Java 1.6 Update 24 for a user although blocklist.xml has been updated. See this thread in the French Support Forum: http://www.geckozone.org/forum/viewtopic.php?f=5&t=104489&p=686430 Correlations in crash stats show that there are still old Java versions: 6.0.100.33 0.05% 6.0.110.3 0.10% 6.0.120.4 0.10% 6.0.130.3 0.05% 6.0.160.1 0.10% 6.0.170.4 0.21% 6.0.180.7 0.10% 6.0.190.4 0.10% 6.0.200.2 0.26% 6.0.210.6 0.10% 6.0.210.7 0.73% 6.0.220.4 1.52% 6.0.230.5 0.52% 6.0.240.7 0.94% 6.0.250.6 0.26% 6.0.260.3 1.67% 6.0.270.7 0.58% 6.0.290.11 4.18% 6.0.300.12 1.93% 6.0.310.5 86.46%
The Java Deployment Toolkit is not being blocked because it isn't vulnerable as far as we know. Also, this is a softblock, meaning that users can opt-out of it. There's also the possibility that some users have disabled blocklisting, which has been suggested in some online forums.
See: https://support.mozilla.org/en-US/questions/926035#question-reply On Firefox 3.6.28, the softblock is killing the current version of Java (build 1.6.0_31-b05). This is not good, particularly since Firefox 4.x - 12.x still have significant issue with memory leaks, and other architectural flaws. I don't believe that blocking the latest version of Java was intended. Because of this error by Mozilla, I am now planning to move my entire Enterprise off the Mozilla platform. This will alleviate my maintenance nightmare created by Mozilla's new versioning scheme. Even the Firefox Extended Support (https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal) doesn't address the issue, particularly since the majority of Firefox developers are independent, and Mozilla has been all over the map trying to achieve consensus among the active participants in Firefox development and management. These guys and gals just can't keep up, particularly if the direction is inconsistent. By the way, the TLS certificate at the previous URL is a security issue, it's issued for a different site name. Mozilla needs to get their own house in order as well. Chaos reigns!
OK guys, apparently this "patch" to the blocklist is overly inclusive. I just updated Java to version 1.6 update 32 (yet to be officially released) and Firefox still blocks the plug-in. This is obviously an error, unless someone here knows something that all of us have missed!
Could it be that there is a typo in the blocklist? The Java line says <versionRange minVersion="0" maxVersion="13.6.0" severity="1"></versionRange> Java is now up to v. 1.6.0_32, released around 28Apr(?), quite some distance from 13.6.0. I updated this morning and promptly got blocked again, so I took the sledgehammer approach and edited the blocklist to <versionRange minVersion="0" maxVersion="1.6.0_30" severity="1"></versionRange> Working fine up to now. Vulnerable? Who knows, but I'm extra careful.
(In reply to Gregg Rasor from comment #108) > just updated Java to version 1.6 update 32 (yet to be officially released) > and Firefox still blocks the plug-in. Can you please post the information that you see in about:plugins about that plugin version? (In reply to r2d2ii.b from comment #109) > Could it be that there is a typo in the blocklist? The Java line says > > <versionRange minVersion="0" maxVersion="13.6.0" > severity="1"></versionRange> This only applies to the Java plugin for Mac, which uses different version numbering.
The 6u32 release does not contain any security fixes. Security fixes for Java SE are included in only Critical Patch Updates, or CPUs. http://www.oracle.com/technetwork/topics/security/javacpufeb2012-366318.html These CPUs are scheduled out about a year in advance. Oracle Java SE Critical Patch Update Schedule The next three dates for Oracle Java SE Critical Patch Updates are: 12 June 2012 16 October 2012 19 February 2013
Java(TM) Platform SE 6 U32 File: npjp2.dll Version: 6.0.320.5 Next Generation Java Plug-in 1.6.0_32 for Mozilla browsers Java Deployment Toolkit 6.0.320.5 File: npdeployJava1.dll Version: 6.0.320.5 NPRuntime Script Plug-in Library for Java(TM) Deploy NOTE: this is for Windows XP, SP3, 32 bit, Firefox 3.6.28 extensions.blocklist.enabled is set to FALSE in order for this pulg-in to run. The blocklist.xml file contains: <blocklist xmlns="http://www.mozilla.org/2006/addons-blocklist" lastupdate="1335893531000"> ... <pluginItem blockID="p85"> <match name="filename" exp="JavaPlugin2_NPAPI\.plugin" /> <versionRange minVersion="0" maxVersion="13.6.0" severity="1"></versionRange> </pluginItem> I hope this helps.
That plugin version should not be blocked. Block p85 applies only to Mac OS (see the filename, JavaPlugin2_NPAPI.plugin). Block p80 is the one that applies to Windows. We do a regular expression match on the description, and it shouldn't match yours, as you can see here: http://mzl.la/KYEm9k
Not sure this should be marked RESOLVED FIXED yet? O.K., so in my Fx 3.6.28 (running under WinXP 32-bit SP3 fully patched), Plugins shows "JAVA(TM) PLATFORM SE 6 U31 6.0.310.5 Next Generation Java Plug-in 1.6.0_31 for Mozilla browsers" active, but "JAVA(TM) PLATFORM SE 6 U31 6.0.310.5 Classic Java Plug-in 1.6.0_31 for Netscape and Mozilla" as deactivated (and the "learn more" link goes to the page for the Mac-only bug). I had no idea I even had two kinds of Java plug-in before! At least my favorite Java applets on the Web continue to work as before. Think this could be handled a little better: (1) remove the offending "Classic" plug-in entirely, do not just deactivate it, (2) make the "learn more" link go to a more appropriate page on bugzilla.
>1) remove the offending "Classic" plug-in entirely, do not just deactivate it We don't remove software that we didn't install. That is in general an unwanted behavior for Software except Antivirus software. Oracle could sue Mozilla for removing their software....
From bug 741592 comment 55: > I have FF 10.0.5 ESR on Win 7 x64. My experience is that 6u31 is permitted > but 6u33 is being blocked because it's outdated?? I've been unable to reproduce this. No versions of Java >= 6u31 are blocked for me.
OK - with 6u31 everything is fine. The plugincheck page says it's outdated but doesn't take action. Then I install 6.0.33 (x32 and x64, the static version alongside 6u31) and start FF again and am asked to approve the .33 addon and hit restart. Now if I go to the Add-ons Manager I don't see Java at all - no .33 or .31 or anything. Visit plugincheck and get the message "Missing JAVA? For your safety, Firefox has disabled your outdated version of Java. Please upgrade to the latest version." which is ironic since I just upgraded to the latest version in the 6 line. I can readily reproduce this on my 10.0.5ESR/W7x64 combination and did so several times yeaterday. I've tried setting "plugin.scan.SunJRE" to 1.7 and "extensions.blocklist.enabled" to false but FF still loses the plugin. (Doesn't just leave it disabled in the addon manager - removes any reference to it from that and about:plugins.) If you want any more info, get back to me?
Just to add, I can't reproduce the problem on XP...
OK - not reproducible on a W7 x32 system either... So is W7 x64 the problem or my computer?
Martin, there are two versions of Java, the 64-bit and 32-bit ones. Firefox uses only the 32-bit version even on a 64-bit OS. Check you installed the 32-bit version.
Yup - 32bit it is. I've just done yet another check. I uninstalled all versions of Java. Installed 6u31 (32bit only) and started firefox. It spotted the new addon and asked me to authorise it and all was well. I then added 6u33 (again 32bit only, again the "static" version) alongside 6u31 and started FF again. Again the new addon is noticed and authorised. FF restarts and all trace of java disappears. blocklist.xml in the program directory is dated 1st June if that's of any relevance, but looking at the regex, if that was the culprit it would affect .31 as well.
(In reply to Martin Sapsed from comment #117) > Then I install 6.0.33 (x32 and x64, the static > version alongside 6u31) and start FF again and am asked to approve the .33 > addon and hit restart. Note that the Java Console add-on which you are being asked to approve is not the same thing as the Java Plugin. Disabling or choosing not to install Java Console should not prevent the plug-in from loading, as far as I know.
OK - so ignoring the bit about the add-on, why is my copy of FF on my machine removing all trace of the Java plugin if it's version 6 update 33???
Martin, I don't think your issue is related to the blocklist. Ask your question in the support forum, https://support.mozilla.org/en-US/questions/new , and report back here in case the blocklist is the cause.
Looks like you're right - I've gone back to 6u29 and with the pref changes mentioned, it's flagged in plugincheck but no more. Even 6u29 isn't annihilated in the same way as poor 6u33 is for me... I've tried the support pages but no joy yet. Someone must know which code is producing the Missing Java comment and removing all trace of the plugin?
Your actual bug is the removing the plugin, which is at the wrong place in this report here, should be discussed in support.mozilla.org, maybe a mailing list or some other bug (though I don't think it's a Mozilla issue, sounds like a Java/Oracle issue). The comment on the website is just triggered by the website not seeing an active Java plugin in your installation. It cannot really detect if it's deactivated or not present, websites like plugincheck only see if Java is active or not, and it warns you when it's not active that this *could* potentially be because of blocking. This can have other reasons as well though, just like in your case.
OK - turned out the problem was some remnants in the registry which caused FF not to see the 6u33 plugin when it was installed. All other versions appeared fine. (Your comment helped point me in the right direction though, along with one on the support page.) Apologies for cluttering up your bug page with inappropriate stuff!
how do i unblock it please can i informed?
(In reply to jawed from comment #128) > how do i unblock it please can i informed? See http://support.mozilla.org/kb/update-and-unblock-java
ff
Because Mazilla has dropped or blocked Jre-6u18 I have been unable to use the site all semester. I have 3 online class that we access through explorer. I am disappointed that I am unable to use mazilla. My online classes are all through Blackboard Learning System, and assignments can only be submitted through jre 6u18. I can't even access the videos or SafeAssign through mazilla. I also cannot update explorer to higher than 18. Since I have no control over the choices of the IT department, I am stuck with explorer alone. Wish this could have been different.
(In reply to joycelbecker from comment #131) See comment 91. Also, you should complain to your IT department because they're forcing you to use software that is nearly 4 years old; unnecessarily exposing you to multiple security vulnerabities.
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.