Closed Bug 812896 Opened 12 years ago Closed 12 years ago

Softblock Java versions affected by CVE-2012-5076

Categories

(Toolkit :: Blocklist Policy Requests, defect)

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

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: decoder, Assigned: jorgev)

Details

(Keywords: qawanted, sec-critical, sec-vector) 

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.
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>
note i will inform oracle about our plans (this bug)
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.
Summary: Softblock Java versions affected by CVE-2012-5076 in Firefox 16 and below → Softblock Java versions affected by CVE-2012-5076
(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.
Updated staging to work up to 17.*
QA Contact: anthony.s.hughes
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
(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?
Assignee: nobody → jorge
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.
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.
Keywords: qawanted
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?
Yes, that's the expected behavior for anything in the Java 7 branch. They should not be blocked on 18 and above.
(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 ?
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.
I am now seeing a softblock for Java 7u7 in Firefox 17. This can be pushed live in my opinion.
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.
Status: RESOLVED → VERIFIED
Keywords: qawanted
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?
Status: VERIFIED → REOPENED
Keywords: qawanted
Resolution: FIXED → ---
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
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.
(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.
(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 ?
(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.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
(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 :)
(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.
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.
(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.
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.