Last Comment Bug 812896 - Softblock Java versions affected by CVE-2012-5076
: Softblock Java versions affected by CVE-2012-5076
Status: RESOLVED FIXED
: qawanted, sec-critical, sec-vector
Product: Toolkit
Classification: Components
Component: Blocklisting (show other bugs)
: unspecified
: All All
: -- critical (vote)
: ---
Assigned To: Jorge Villalobos [:jorgev]
: Anthony Hughes (:ashughes) [GFX][QA][Mentor]
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-18 09:53 PST by Christian Holler (:decoder)
Modified: 2016-03-07 15:30 PST (History)
19 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Christian Holler (:decoder) 2012-11-18 09:53:11 PST
In October Oracle released a critical security update fixing several issues, including  CVE-2012-5076 (see http://www.oracle.com/technetwork/topics/security/javacpuoct2012-1515924.html). This bug affects Java 7u7 and below, though the Java 6 branch seems to be unaffected.

Recently, an exploit for this bug was found in the Cool exploit pack: http://malware.dontneedcoffee.com/2012/11/cool-ek-hello-my-friend-cve-2012-5067.html

Furthermore, the exploit was added to the Metasploit framework now.

It is already planned that the affected versions are CTP in Firefox 17 and higher, but now that the exploit is public, we should also block them in Firefox 16 and below to protect our users from drive-by malware infections.
Comment 1 Justin Scott [:fligtar] 2012-11-18 11:53:11 PST
These are now on staging (addons-dev.allizom.org):

<pluginItem  blockID="p209">
      <match name="name" exp="Java\(TM\) Plug-in 1\.7\.0(_0?([5-7]))?([^\d\._]|$)" />
      <match name="filename" exp="libnpjp2\.so" />
      <versionRange  severity="1">
           <targetApplication  id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
                <versionRange  minVersion="0.1" maxVersion="16.*" />
           </targetApplication>
      </versionRange>
</pluginItem>

<pluginItem  blockID="p211">
      <match name="filename" exp="JavaAppletPlugin\.plugin" />
      <versionRange  minVersion="Java 7 Update 05" maxVersion="Java 7 Update 07" severity="1">
           <targetApplication  id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
                <versionRange  minVersion="0.1" maxVersion="16.*" />
           </targetApplication>
      </versionRange>
</pluginItem>

<pluginItem  blockID="p213">
      <match name="name" exp="Java\(TM\) Platform SE 7 U[5-7](\s[^\d\._U]|$)" />
      <match name="filename" exp="npjp2\.dll" />
      <versionRange  severity="1">
           <targetApplication  id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
                <versionRange  minVersion="0.1" maxVersion="16.*" />
           </targetApplication>
      </versionRange>
</pluginItem>
Comment 2 Carsten Book [:Tomcat] 2012-11-18 13:18:57 PST
note i will inform oracle about our plans (this bug)
Comment 3 Alex Keybl [:akeybl] 2012-11-18 14:08:22 PST
Due to bug 811375 (which will prevent the Java CTP block from being functional at FF17 launch), we'll actually need this block to cover Firefox 17 as well. Apologies for the churn, this is news to us as well.
Comment 4 Alex Keybl [:akeybl] 2012-11-18 15:04:26 PST
(In reply to Alex Keybl [:akeybl] from comment #3)
> Due to bug 811375 (which will prevent the Java CTP block from being
> functional at FF17 launch), we'll actually need this block to cover Firefox
> 17 as well. Apologies for the churn, this is news to us as well.

We'll actually track the bug preventing us from using Java CTP in FF17 in bug 812927.
Comment 5 Justin Scott [:fligtar] 2012-11-18 16:17:31 PST
Updated staging to work up to 17.*
Comment 6 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-11-19 13:04:49 PST
We encountered several issues in testing this staged block. None of which were problems with the block itself but did affect our ability to test the block.

In many cases, we found old Java versions to be disabled on first run. 
 * Java 7u5 on all platforms
 * Java 7u6 on Windows and Mac
 * Java 7u7 on Windows
In these cases, we could enable the plugin in Add-ons Manager and test the staged block.

Juan encountered conflicting issues with OSX 10.8 testing. As with above, he saw the Java versions being disabled on first-run. However, on one machine he was not able to get Java content to load at all (even after enabling Java or updating to 7u9). On another machine, he kept being prompted to install Java SE 6 when loading Java content. Firefox whenever I try to load an applet. 

Juan, feel free to elaborate further.

Reference: https://wiki.mozilla.org/User:Ashughes/Test_Plans/CVE-2012-5076
Comment 7 Alex Keybl [:akeybl] 2012-11-19 16:12:02 PST
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #6)
> We encountered several issues in testing this staged block. None of which
> were problems with the block itself but did affect our ability to test the
> block.
> 
> In many cases, we found old Java versions to be disabled on first run. 
>  * Java 7u5 on all platforms
>  * Java 7u6 on Windows and Mac
>  * Java 7u7 on Windows
> In these cases, we could enable the plugin in Add-ons Manager and test the
> staged block.

jorgev - can you confirm that we're not running into any pre-existing blocks here?
bsmedberg - could anything other than blocks be causing these Java versions to start disabled?
Comment 8 Jorge Villalobos [:jorgev] 2012-11-20 09:13:07 PST
Java 7, update 6 and below are already softblocked both in staging and prod:

https://addons.mozilla.org/en-US/firefox/blocked/p138
https://addons.mozilla.org/en-US/firefox/blocked/p134
https://addons.mozilla.org/en-US/firefox/blocked/p132

So, it sounds like what we need to do is limit these existing blocks so that they only apply up to 17.*, and add similar blocks for update 7 only.
Comment 9 Jorge Villalobos [:jorgev] 2012-11-20 12:40:14 PST
The blocks are now staged.

The following existing blocks for Java are now restricted to 17.* and below: 138, 134, 132, 125, 123, 119. These were introduced in bug 780717, bug 794247 and their dependencies.

I modified the blocks from comment #1 so that they only apply to Java 7 update 7, in order to avoid any overlap.

QA, please verify so we can apply this on prod.
Comment 10 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-11-20 13:10:05 PST
Here are the results of my testing.
* Java 7u7 in Firefox 17.0 was click-to-play blocked
* Java 7u7 in Firefox 16.0.2 was softblocked
* Java 7u7 in Firefox 16.0 was softblocked

Is this expected?
Comment 11 Jorge Villalobos [:jorgev] 2012-11-20 14:52:08 PST
Yes, that's the expected behavior for anything in the Java 7 branch. They should not be blocked on 18 and above.
Comment 12 Paul Silaghi, QA [:pauly] 2012-11-21 03:04:17 PST
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #10)
> Here are the results of my testing.
> * Java 7u7 in Firefox 17.0 was click-to-play blocked
> * Java 7u7 in Firefox 16.0.2 was softblocked
> * Java 7u7 in Firefox 16.0 was softblocked
> 
> Is this expected?

J7u7 shouldn't be softblocked and not CTP blocked in FF 17 ?
Comment 13 Jorge Villalobos [:jorgev] 2012-11-21 08:37:39 PST
You're right. I hadn't made the changes from bug 812936 on staging, so the previous CTP blocks still applied to Firefox 17. I fixed this now.
Comment 14 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-11-21 12:55:52 PST
I am now seeing a softblock for Java 7u7 in Firefox 17. This can be pushed live in my opinion.
Comment 16 Jorge Villalobos [:jorgev] 2012-11-22 09:48:23 PST
I also published this in the Add-ons Blog:
https://blog.mozilla.org/addons/2012/11/22/java-7-update-7-blocked/
Comment 17 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-11-22 12:55:55 PST
Results of testing the live block with Firefox 17.0, 16.0, 16.0.1, and 16.0.2 on Windows 7, OSX 10.7, and Ubuntu 12.04:
 * Java 7u7 was softblocked on ping
 * Java 7u4 was hardblocked on firstrun
 * Java 7u3 was hardblocked on firstrun
 * Java 6u32 was hardblocked on firstrun
 * Java 6u31 was hardblocked on firstrun

Marking this bug verified fixed. Please reopen if the hardblocks are unexpected.
Comment 18 Jorge Villalobos [:jorgev] 2012-11-23 10:34:30 PST
The hardblocks are definitely unexpected. Looking at blocklist.xml, I see the severity set to 1, which is the correct value for a softblock.

Can you please check again?
Comment 19 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-11-23 14:04:48 PST
I just spotchecked this again on a completely new Windows 7 install with Java 7u4 and it is disabled on firstrun in the Addons Manager (before doing any blocklist pings).

Here is what I see in my blocklist.xml:
<pluginItem blockID="p119">
     <match name="name" exp="Java\(TM\) Plug-in 1\.(6\.0_(\d|[0-2]\d?|3[0-2])|7\.0(_0?([1-4]))?)([^\d\._]|$)"/>
     <match name="filename" exp="libnpjp2\.so"/>
     <versionRange severity="1"/>
</pluginItem>
<pluginItem blockID="p125">
     <match name="name" exp="Java\(TM\) Platform SE ((6( U(\d|([0-2]\d)|3[0-2]))?)|(7(\sU[0-4])?))(\s[^\d\._U]|$)"/>
     <match name="filename" exp="npjp2\.dll"/>
     <versionRange severity="1"/>
</pluginItem>

Here is what shows in my Add-ons Manager:
Java(TM) Platform SE 7 U4 10.4.0.20 (disabled)
Next Generation Java Plug-in 10.4.0 for Mozilla browsers
Comment 20 Jorge Villalobos [:jorgev] 2012-11-23 14:39:44 PST
It could be a bug in the way the Add-ons Manager handles the default blocklist. Those blocks have the right severity, but for reason they are behaving as hardblocks.

Adding the AOM people for comment.
Comment 21 Paul Silaghi, QA [:pauly] 2012-11-26 04:54:56 PST
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #19)
> I just spotchecked this again on a completely new Windows 7 install with
> Java 7u4 and it is disabled on firstrun in the Addons Manager (before doing
> any blocklist pings).

If the plugin is disabled and can be enabled, it doesn't mean is softblocked ?
That's the behavior I see on FF 17.
Comment 22 Paul Silaghi, QA [:pauly] 2012-11-26 05:37:23 PST
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #17)
> Results of testing the live block with Firefox 17.0, 16.0, 16.0.1, and
> 16.0.2 on Windows 7, OSX 10.7, and Ubuntu 12.04:
>  * Java 7u7 was softblocked on ping

Before the ping, j7u7 is CTP blocked. Where is this block coming from ?
Comment 23 Jorge Villalobos [:jorgev] 2012-11-26 07:49:45 PST
(In reply to Paul Silaghi [QA] from comment #21)
> (In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #19)
> > I just spotchecked this again on a completely new Windows 7 install with
> > Java 7u4 and it is disabled on firstrun in the Addons Manager (before doing
> > any blocklist pings).
> 
> If the plugin is disabled and can be enabled, it doesn't mean is softblocked
> ?
> That's the behavior I see on FF 17.

Yes. If that's what you see, then that is correct. I'm marking this as fixed again then.

(In reply to Paul Silaghi [QA] from comment #22)
> (In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #17)
> > Results of testing the live block with Firefox 17.0, 16.0, 16.0.1, and
> > 16.0.2 on Windows 7, OSX 10.7, and Ubuntu 12.04:
> >  * Java 7u7 was softblocked on ping
> 
> Before the ping, j7u7 is CTP blocked. Where is this block coming from ?

IIRC, Firefox includes the latest version of the blocklist before it was built, so that it at least has a relatively current version to apply before the first blocklist download.
Comment 24 Blair McBride [:Unfocused] (mostly unavailable, needinfo open, reviews not) 2012-11-26 14:14:25 PST
(In reply to Jorge Villalobos [:jorgev] from comment #23)
> IIRC, Firefox includes the latest version of the blocklist before it was
> built, so that it at least has a relatively current version to apply before
> the first blocklist download.

Correct.

Glad this got sorted :)
Comment 25 Paul Silaghi, QA [:pauly] 2012-11-27 01:24:53 PST
(In reply to Jorge Villalobos [:jorgev] from comment #23)
> > Before the ping, j7u7 is CTP blocked. Where is this block coming from ?
> 
> IIRC, Firefox includes the latest version of the blocklist before it was
> built, so that it at least has a relatively current version to apply before
> the first blocklist download.

Don't know the solution, but it would be nice to have one. Our users will be confused by the CTP, until the ping is made.
BTW, how long will take until the ping arrives? I see it in about 5-10 minutes in FF 17.
Comment 26 Jorge Villalobos [:jorgev] 2012-11-27 09:03:00 PST
If you force the ping, it should happen almost immediately. Without forcing the ping, it can take up to 24 hours. I think we'll have to live with this when it comes to changing the behavior of existing blocks.
Comment 27 Blair McBride [:Unfocused] (mostly unavailable, needinfo open, reviews not) 2012-11-27 14:33:43 PST
(In reply to Jorge Villalobos [:jorgev] from comment #26)
> If you force the ping, it should happen almost immediately. Without forcing
> the ping, it can take up to 24 hours. I think we'll have to live with this
> when it comes to changing the behavior of existing blocks.

FWIW, filed bug 815809, which will address the new-install case of this.

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