Closed Bug 741592 Opened 11 years ago Closed 11 years ago

[Mac] 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: fligtar, Assigned: jorgev)

References

Details

(Keywords: qawanted, Whiteboard: [plugin][softblock][mac only][Apple bug rdar://11185267]) 

+++ This bug was initially created as a clone of Bug #739955 +++

This is the Mac-focused portion of bug 739955 which blocks Java due to actively exploited security vulnerabilities.
I just staged a test version of the Java block for Mac OS. It covers the version range from 0 to 14.1.0 for files JavaPlugin2_NPAPI.plugin and JavaAppletPlugin.plugin.

https://addons-dev.allizom.org/en-US/firefox/blocked/p83

QA, please test again.
Keywords: qawanted
Testing using Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20100101 Firefox/12.0 with a fresh profile.

I see https://addons-dev.allizom.org/en-US/firefox/blocked/p83 in my blocklist.xml file, but it is not blocking Java.

Java version:     
    File: JavaPlugin2_NPAPI.plugin
    Version: 13.6.0
    Java Plug-In 2 for NPAPI Browsers
Jorge: I don't understand the relationship between the 'p83 link and the regexp you are using. Can you share the actual regexp?
AMO seems to be adding an unnecessary node in the blocklist. I'll try to get this corrected tomorrow.

(In reply to Bob Clary [:bc:] from comment #3)
> Jorge: I don't understand the relationship between the 'p83 link and the
> regexp you are using. Can you share the actual regexp?

This block doesn't use a regexp to identify the plugin. In this case we're only filtering by file name and plugin version.
Depends on: 741841
When I checked for update on my 10.6 and 10.7 Mac today, they pushed a Java update. However, the link to details about it is broken: http://support.apple.com/kb/HT5056

http://support.apple.com/kb/HT1222 is supposed to have info as well about the content of the update.

On 10.6, the update is Java for Mac OS X 10.6 Update 7, Version 7.
I just checked for updates, and the link was http://support.apple.com/kb/HT5055
It says:

> This release updates Java SE 6 to version 1.6.0_31.

> This release is for OS X v10.7 or later versions of OS X.
After updating, this is the plugin info I have:

    File: JavaAppletPlugin.plugin
    Version: 14.0.3
    Displays Java applet content, or a placeholder if Java is not installed.

I need to know the analogous info for those who have JavaPlugin2_NPAPI.plugin instead, to see if there are any adjustments needed for the block.
Here is the info from my 10.6 machine after updating:

Java Plug-In 2 for NPAPI Browsers

    File: JavaPlugin2_NPAPI.plugin
    Version: 13.7.0
    Java Plug-In 2 for NPAPI Browsers
Correction: I get version 14.2.0. For some reason my main profile wasn't updated the plugin and I had to delete pluginreg.dat to pick up the updated version.
OK, given this new information, I have staged 2 blocks:

https://addons-dev.allizom.org/en-US/firefox/blocked/p83 for JavaAppletPlugin.plugin up to version 14.1.0

https://addons-dev.allizom.org/en-US/firefox/blocked/p84 for JavaPlugin2_NPAPI.plugin up to version 13.6.0

Please test again and let me know if the block is working now.
Here are the results of my testing with the staged block from Comment 10:

Mac 10.7.4: Java version 14.1.0 is disabled in about:plugins and no java content is rendered
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20100101 Firefox/12.0

Mac 10.5.8: Java version 12.9.0 is disabled in about:plugins and no java content is rendered.
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0) Gecko/20100101 Firefox/12.0

Mac 10.6.8: Tried the block on two different lab machines that both have Java version 13.6.0, but the block doesn't work for some reason on these machines.
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20100101 Firefox/12.0
Is the plugin file name on those 2 machines JavaPlugin2_NPAPI.plugin?
Gah! It looks like addons-dev was reset, so I need to add the blocks again.
Confirming on both 10.6 machines (JavaPlugin2_NPAPI.plugin) that the staged block https://addons-dev.allizom.org/en-US/firefox/blocked/p81 works using Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20100101 Firefox/12.0.

I can retest the block on 10.7 and 10.5 but it did work the first time it was staged in Comment 10.
and fwiw apple has just relased a update - Java for OS X 2012-001 and Java for Mac OS X 10.6 Update 7, which addresses this vulnerability
There are a couple of problems that could stop us from blocking on Mac:

1) The info.plist for the latest version of the plugin still sets
<key>application/x-java-applet;jpi-version=1.6.0_29</key>
This means that the plugin check page will always tell users they have a vulnerable version.

2) Bug 313700. Some users might remain permanently blocked because the plugin metadata isn't reloaded even after the new version is installed and Firefox is restarted.
Depends on: 313700
Whiteboard: [plugin][softblock][mac only] → [plugin][softblock][mac only][Apple bug rdar://11185267]
Judging by bug 313700 comment #31, we can't proceed with the block until that bug is fixed, or Apple changes the way the plugin is updated. It still important that Apple addresses issue #1 and, ideally, that they also change their update code to work around bug 313700.

As things stand right now, I don't think we can proceed with this block.
I think we need to weigh the costs and benefits of blocking vs not blocking.

What percentage of our Mac users need to have Java enabled at all? If a user doesn't need Java and we fail to protect them by blocking vulnerable versions of Java, the cost to them may be a compromised machine with unknown financial and privacy losses. I assert (without evidence unfortunately) that the percentage of users who do not need Java enabled far exceeds the percentage that do need it enabled.

If a user does need Java and we do block them, they can update Java and delete pluginreg.dat to re-enable it, correct? The cost to the user will be a temporarily disabled Java plugin that with some education and help from us can be updated and re-enabled without too much effort.

We can provide instructions on the blocking page, right? Can we help by providing a hot-fix that will delete pluginreg.dat without asking the user to do so manually?
Just as another source of information: According to Dr. Web, 600000 users are already infected now with the Flashback trojan, which spreads through exactly this Java vulnerability: See also https://twitter.com/#!/hexminer/status/187623741273026562
(In reply to Bob Clary [:bc:] from comment #19)
> We can provide instructions on the blocking page, right?
Yes, but most users won't find it, nor any other information we put out there.

> Can we help by providing a hot-fix that will delete pluginreg.dat without asking
> the user to do so manually?

That's one possibility, yes. However, the changes don't take effect until Firefox is restarted, meaning that we can't do this completely transparently. It would also be difficult for the hot fix add-on to figure out whether it needs to do anything, given that the plugin would be reporting an incorrect version number.

We could give this a few days so that the Mac OS update propagates enough and then just do the block for the minority (?) that is left with an old version of Java.

Either way, we're putting many users in a situation where they won't know what to do to move forward.
This is the new Apple fix for OS X Lion.

Java for OS X Lion 2012-002 (the update before the fix was "Java for OS X Lion 2012-001")

http://support.apple.com/kb/DL1515
Sorry, I don't know why, but few minutes ago if you clicked on the link in my previous message, on that page it was reported "Java for OS X Lion 2012-002". 

Now is "Java for OS X Lion 2012-001" again...

According to the Apple downloads page
http://support.apple.com/downloads/
Apple reports the availability of "Java for OS X Lion 2012-002" for download...

It's better that Lion users (I use SnowLeopard OS X 10.6) check via menu Apple > "Software update..."
I just got a new Java update for Mac 10.7 (Java for OS X Lion 2012-002) this morning. The Java Preference app says I now have Java SE 6 Version 1.6.0_31-b04-414 but my plugin version has not changed (with either update) and plugin check lists it as vulnerable. Not sure what to tell users about this.
(In reply to Verdi from comment #24)
> I just got a new Java update for Mac 10.7 (Java for OS X Lion 2012-002) this
> morning. The Java Preference app says I now have Java SE 6 Version
> 1.6.0_31-b04-414 but my plugin version has not changed (with either update)
> and plugin check lists it as vulnerable.

Try closing Firefox, deleting pluginreg.dat from the profile folder and starting again. This is the problem described in bug 313700.
(In reply to Jorge Villalobos [:jorgev] from comment #25)
> Try closing Firefox, deleting pluginreg.dat from the profile folder and
> starting again. This is the problem described in bug 313700.

That did the trick. So my question is, is that step required? Are people vulnerable if they don't this?
I just installed Java for OS X 2012-002 and the issue now appears to be resolved

% sw_vers
ProductName:	Mac OS X
ProductVersion:	10.7
BuildVersion:	11A2063
% grep jpi-version /System/Library/Java/Support/CoreDeploy.bundle/Contents/JavaAppletPlugin.plugin/Contents/Info.plist
		<key>application/x-java-applet;jpi-version=1.6.0_31</key>

Can we move forward with the blocklist testing and pushing to production given this?
I tested the staged blocklists in Comments 11 and 15 - it is not clear to me at this point what needs to be tested.

> 
> Can we move forward with the blocklist testing and pushing to production
> given this?
(In reply to Alex Keybl [:akeybl] from comment #27)
> I just installed Java for OS X 2012-002 and the issue now appears to be
> resolved
> 
> % sw_vers
> ProductName:	Mac OS X
> ProductVersion:	10.7
> BuildVersion:	11A2063
> % grep jpi-version
> /System/Library/Java/Support/CoreDeploy.bundle/Contents/JavaAppletPlugin.
> plugin/Contents/Info.plist
> 		<key>application/x-java-applet;jpi-version=1.6.0_31</key>
> 
> Can we move forward with the blocklist testing and pushing to production
> given this?

I do want to point out that my about:plugins has application/x-java-applet;jpi-version=1.6.0_24 even after that update. I'm guessing that's bug 313700.
So, because of bug 313700, even after updating your Java plugin there's a possibility that it will still be reported as the old version, and I believe that the block will continue to be applied.

(In reply to Verdi from comment #26)
> So my question is, is that step required? Are people vulnerable if they don't this?

Deleting pluginreg.dat would probably be required to remove all blocklist warnings. People are *not* vulnerable, though. They are using the new version of the plugin, but the version is misreported.

It'd be good to get confirmation from QA if the block continues to show up even after updating to a safe version, provided that you manage to reproduce the bug where the old version continues to appear. If this is confirmed, then we have to choose between leaving users unsafe or annoying them with a semi-permanent softblock.
(In reply to Jorge Villalobos [:jorgev] from comment #30)
> It'd be good to get confirmation from QA if the block continues to show up
> even after updating to a safe version, provided that you manage to reproduce
> the bug where the old version continues to appear. If this is confirmed,
> then we have to choose between leaving users unsafe or annoying them with a
> semi-permanent softblock.

I've reproduced bug 313700 in Comment 29, so I'm trying to test the block to verify the behavior. Looks like it's missing though. Can we repost https://addons-dev.allizom.org/en-US/firefox/blocked/p83?
Actually strike that. I was able to test https://addons-dev.allizom.org/en-US/firefox/blocked/p80. I can confirm that on 10.7, after updating to Java applet version 1.6.0_31, I'm offered the softblock (and about:plugins shows jpi-version=1.6.0_24).
Alex: Did you test the block before you actually updated your version of Java on that 10.7 machine?

Testing with 10.6.8 here is what I am seeing:

1. Start with a machine that has not been updated to the new version of Java (running 1.6.0_29)
2. Check about:plugins and confirm that the version shows as 1.6.0_29
3. Perform an Apple Software update to pick up the latest version of Java 1.6.0_31.
4. Check about plugins - browser shows Java 1.6.0_31.

So it doesn't seem we are getting consistent results as far as the browser showing the correct/incorrect version of the plugin version.
I will have to check a few more of the machines that I have to see if I get the same results in Comment 33 on both 10.6 and 10.7. Alex and Verdi both seem to be running 10.7 so I am wondering if anyone on 10.6 has seen the plugin version mismatch issue after applying the Apple update.
(In reply to Marcia Knous [:marcia] from comment #33)
> Alex: Did you test the block before you actually updated your version of
> Java on that 10.7 machine?

No, only afterwards. My expectation is that the block would have appeared prior as well.
Testing on 10.7 with the same steps as in Comment 3, I see the following using the latest Firefox nightly:

1. Start with a 10.7 machine that has not been updated to the new version of Java (running 1.6.0_29)
2. Check about:plugins java - version and confirm that the version shows as 1.6.0_29
3. Perform an Apple Software update to pick up the latest version of Java 1.6.0_31.
4. Check about plugins - browser shows Java 1.6.0_29 in my existing profile.
5. If I create a new profile the new profile shows the correct version, 1.6.0_31.
Per the request in the channel meeting, I will be providing the 10.5 java version.
Here is the Java information I have from the 10.5 machines in the lab. Both machines are running version 10.5.8.

From the browser:

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


From the 10.5.8 Mac terminal:

host-5-255:~ mozilla$ java -version
java version "1.5.0_30"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_30-b03-389-9M3425)
Java HotSpot(TM) Client VM (build 1.5.0_30-161, mixed mode, sharing)
That version would be blocked by p81, which covers all versions from 0 to 13.6.0 of JavaPlugin2_NPAPI.plugin
(In reply to Jorge Villalobos [:jorgev] from comment #39)
> That version would be blocked by p81, which covers all versions from 0 to
> 13.6.0 of JavaPlugin2_NPAPI.plugin

Yeah, these versions would be covered by the previously staged block. But we're trying to only block older 10.5 versions of Java on OSX while we wait to get bug 313700 into the release (FF12). Can we prepare that?
I just modified the staged p81 block to have a max version of 12.9.0. Please verify that it works.
Bug 313700 will land in FF13 and FF12 shortly. That means that we should plan to move ahead with the blocklist for all affected versions of Java after release on 4/24. SUMO can advise users to update to FF12 if their version of Java is being incorrectly blocked.
Please scroll to the bottom of https://etherpad.mozilla.org/Java-Testing to see QA testing results for the staged block related to Mac 10.5.
> PASS using Beta 5. Java version is blocked and can be enabled
> Java content does not show when it has been blocked
> FAIL using latest trunk. Java version can be enabled but no content shows when it
> is enabled, and then Firefox hangs and you have to force quit.

Could that failed case be related to the fix for bug 313700?
Probably not since I checked 20120409 build and the bug was still there, and this was before that checkin.

(In reply to Jorge Villalobos [:jorgev] from comment #44)
> > PASS using Beta 5. Java version is blocked and can be enabled
> > Java content does not show when it has been blocked
> > FAIL using latest trunk. Java version can be enabled but no content shows when it
> > is enabled, and then Firefox hangs and you have to force quit.
> 
> Could that failed case be related to the fix for bug 313700?
These test results look good. Let's move forward with the 10.5 block.
I modified the max version of the existing block, and it now covers all vulnerable versions:

https://addons.mozilla.org/en-US/firefox/blocked/p85

New blog post:

http://blog.mozilla.org/addons/2012/04/30/java-block-complete-for-mac-os-x/
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Apparently, this "fix" has crept into the Windows version of Firefox 3.6.28.  See: https://support.mozilla.org/en-US/questions/926035#question-reply  It happened to me this morning, and I am now planning to move my entire Enterprise off the Mozilla platform for this reason, along with the 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.  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!
Java was blocked for Windows in bug 739955. It was announced here:
http://blog.mozilla.org/addons/2012/04/02/blocking-java/

There's a mailing list for the Enterprise Working Group, in case you have questions about overriding the blocklist or the extended support version, which you don't seem to understand:
https://wiki.mozilla.org/Enterprise#How_to_Participate_and_Post
"Who is affected?
    All Firefox users who have installed the Java plugin, JRE versions below 1.6.0_31 or between 1.7.0 and 1.7.0_2."

So all versions below 1.6.0_31 right? then why is it blocking 1.6.0_31. 

Also it is not (thank goodness) blocking all of the java add-ons. 

It is blocking "Java(TM) Platform SE 6 U31 6.0.310.5 Classic Java Plug-in 1.6.0_31 for Netscape and Mozilla". But it is not blocking "Java(TM) Platform SE 6 U31 6.0.310.5 Next Generation Java Plug-in 1.6.0_31 for Mozilla browsers"

From my reading of https://addons.mozilla.org/en-US/firefox/blocked/p85, neither of these should be blocked because they are 1.6.31 or higher. 

Oracle just released 1.6.32 last week. But it contains NO security fixes in it. You have effectively killed all 1.6 java (well half anyway because it isn't blocking both add-ons). 

As of April 27, 2012 the latest version of Java 6 is 1.6.0_32 (Version 6 Update 32).  According to Oracle, "This release includes bug fixes and performance improvements." No security patches.

So there is clearly something not right here.
And all of this would be very well and good if you could actually install Jave v6 update 32. I have tried both the Wizard and standalone version and neither will complete the install:

http://www.java.com/en/download/help/wizard_interrupt.xml

Since I uninstalled the previous version once FF disabled it before proceeding with the attempts at v6 update 32 I now have no Java installed or any way to get back to an installable version.

I would far prefer to be given an option, rather than be nannied right out of Java altogether. Java is aware of the current installer problem, has no idea why it happens, and has no time frame for a fx.

"Status: PROBLEM RESOLVED" - you gotta be kidding.
Can anyone make a suggestion, I have a Mac, and I've deleted my firefox browser and all backup files on this Java plug-in, then I download a new version of Firefox, and with a day or so, the NPAPI comes back out of no where... How do I get rid of this thing once and for all?
Mac OS X will always have Java installed and enabled by default, so there's little you can do to avoid that. If you don't want Java in Firefox, all you need to do is go to the Add-ons Manager, select the Plugins pane, and then disable it. It'll continue to be listed, but at least it won't be active.
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?? Something isn't right somewhere methinks. Some of our corporate app suppliers are dragging their feet on Java versions again and don't yet support 7 so I need a current version of 6 working...
Martin, this bug is specific to the Mac blocklist. I'm trying to reproduce your issue but lets take that over to bug 739955.
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #56)
> Martin, this bug is specific to the Mac blocklist. I'm trying to reproduce
> your issue but lets take that over to bug 739955.

See https://bugzilla.mozilla.org/show_bug.cgi?id=739955#c116
CAN YOU PLZ UNBLOCK MY VERSION PLEASE!? GIVE ME AN "OVER-RIDE" as i know what i am doing? and ps.... i am not using a mac thank you.
(In reply to gusgando from comment #58)
> CAN YOU PLZ UNBLOCK MY VERSION PLEASE!? GIVE ME AN "OVER-RIDE" as i know
> what i am doing? and ps.... i am not using a mac thank you.

This was not a hard block, in that you should be able to go to the add-ons manager and re-enable the plug-in if you so choose. Note that this probably isn't the best forum for support as this is a bug report for delivering the block, which is complete. I would recommend taking these sorts of requests to support.mozilla.org in the future.
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.