+++ This bug was initially created as a clone of Bug #803152 +++
<mcoates> can someone file a bug to extend CTP for all versions of Java again. Please mention in the bug that manual blocking by version is an intermediate process until the reamining changes for CTP are implemented (per blog post)

(In reply to Michael Coates [:mcoates] from comment #2)
> We've previously applied CTP for the Java plugin, up to and including, the
> current version. Per our blog post plan to soon CTP all versions of Java.
> During this interim there is a small window where new versions of Java will
> only have CTP if we specifically enable it. Based upon items 1 and 2 above
> we should continue applying CTP to Java at this time.
Sounds good to me. Sounds like we'll file a separate bug for when we want to block Java versions *.*.

Why wouldn't we change the blocklist to *.* now rather than this per-version updating? It seems more likely that we'll keep blocking until something changes than that we'll want to keep evaluating each version as it comes out.

(In reply to Daniel Veditz [:dveditz] from comment #4)
> Why wouldn't we change the blocklist to *.* now rather than this per-version
> updating? It seems more likely that we'll keep blocking until something
> changes than that we'll want to keep evaluating each version as it comes out.
I endorse this approach if it is possible. It seems to be costing a lot more resources to constantly do these blocks than it would if we blocked everything and unblocked known good versions.

We decided a couple releases ago only to deploy the java blocks when a vulnerability was credible, and wait for the better UI to turn CtP on by default. But showing users the scary "your plugin is insecure" UI without actually being able to point to a vulnerability is IMO not a good choice.
If we believe that Java is so far gone that it cannot be secure, we should go ahead and say that publicly and block all versions with a pointer to our statement.

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #16)
> The following appear to be broken:
> > Java Plugin 7 update 12 to 15 (click-to-play), Mac OS X
>
> I'll have to double check Java 7u{12-15} on Mac before signing off for push
> to production.
I confirm this block is not working as expected.
> Already installed Java 7u13
1. Start Firefox with a new profile
2. Change addons.mozilla.org to addons-dev.allizom.org in extensions.blocklist.url
3. Change extensions.blocklist.interval to 10
4. Restart Firefox
5. Force a blocklist ping by evaluating the following code in Error Console
> Components.classes["@mozilla.org/extensions/blocklist;1"].getService(Components.interfaces.nsITimerCallback).notify(null);
6. Load some of the Java demos from here
> http://neuron.eng.wayne.edu/software.html
Result:
A Java window appears asking for my permission to execute the app. Checking "I accept..." and clicking "Run" loads the app.
Given these results my recommendation would be to push the remaining blocks live and figure out what's going on here in a follow-up bug.

The problem is server-side. I noticed this when staging the blocks, but I thought it was a temporary caching problem. If you go to the staging blocklist page (https://addons-dev.allizom.org/en-US/firefox/blocked/), the Mac OS block (283) is not listed, and the Windows block (285) is listed twice. The same is happening in the downloaded blocklist.xml.
I'll file a bug this, and create a new Mac OS block so we can test it.

What do you mean by "don't work" ?
You just have to click on the plugin screen and the java content should be displayed. That message in Addons Manager only warns you to use with caution, java is very vulnerable lately.

(In reply to Paul Silaghi [QA] from comment #29)
> What do you mean by "don't work" ?
> You just have to click on the plugin screen and the java content should be
> displayed. That message in Addons Manager only warns you to use with
> caution, java is very vulnerable lately.
pls cant how me in pictures?? dont speak very good english

There is something I don't catch here.
We were used to quite secure versions of Java, from time to time an issue was discovered and fixed.
My Java was obsolete on an old system of mine that I do not use often, my Firefox blocked it so I went to Oracle's site and installed JRE 7. It was JRE 7.10.
I restarted Firefox and the Java plugin was OK (no warning of being vulnerable, not blocked). But I still got a warning that my Java was not the latest version (!). Strange, I just installed the latest available runtime (as far as I knew).
Anyway I clicked on the update button, it downloaded the whole Java stuff and it was Java 7 Update 15.
Ok.
Now I restart Firefox, and guess what, "Java 7.15 is known to be vulnerable" (this is the object of this thread).
Thus:
- JRE 7.10 is OK and not blocked BUT not the latest version
- JRE 7.15 is the latest version BUT should be blocked
What I do not understand is, why does the plugin system advise people to upgrade from 7.10 to 7.15 if it breaks the security ?

My experience is the exact same as Michael Smith's in comment number 41. I'll ask the same question that he does "why does the plugin system advise people to upgrade from 7.10 to 7.15 if it breaks the security ?"

@ Michael Smith, mine gives me one of those messages as well, so me not knowing and seeing that amongst all these crashes, disabled it myself mine was version Platform SE 7 U15, well now that I look it does say something about a new version 10.15.2, Maybe that'll do the trick....

For the most part it's working fairly decent today so far, don't wanna jinx things though, but yea, there's been a few times of that Shockwave message, and several times I would get Script Error's not related to Shockwave (I guess), BUT I am running all my computer scans right now also, don't know if it's helping or if it really doesn't matter about it, I just checked my plugin's and they finally say they are up to date now, so maybe....

So I wonder, when do guys start blocking flash and adobe reader plugin automatically?
I don't understand why java should be handled differently than e.g. flash, which receives emerency updates all the time, too.

(In reply to Clemens Eisserer from comment #49)
> So I wonder, when do guys start blocking flash and adobe reader plugin
> automatically?
Those are also blocked, but only some older versions.
https://wiki.mozilla.org/Blocklisting/PluginBlocks> I don't understand why java should be handled differently than e.g. flash,
> which receives emerency updates all the time, too.
Because even the latest version of java proved to vulnerable. You can find more articles about java vulnerabilities on google.

(In reply to Clemens Eisserer from comment #49)
> I don't understand why java should be handled differently than e.g. flash,
> which receives emerency updates all the time, too.
First because there are no Flash vulnerabilities known to be exploited in the wild.
Then because Flash blocking will be considered as a war declaration for websites that live with ads. An experiment of ad blocking by a French provider (intending to get paid by Google for huge pipes required by YouTube) was received like that.

> First because there are no Flash vulnerabilities known to be exploited in the wild.
The new vulnerability found in u15 isn't exploited. A company reported it to Oracle, the same happends at Adobe frquently, too.
> Then because Flash blocking will be considered as a war
> declaration for websites that live with ads.
So flash isn't blocked because it is used for adds. The few java-applets left that actually do useful stuff are.
Anyway, who am I to complain.

We are working on rolling out Flash blocks. We currently block Flash 10.2 and lower on release, and old versions of 10.3 on Beta. Flash is more tricky because there are more users / websites which is why we are slowly rolling the blocks out. Eventually the blocks will grow to more and more versions of Flash.

(In reply to Clemens Eisserer from comment #52)
> > First because there are no Flash vulnerabilities known to be exploited in the wild.
>
> The new vulnerability found in u15 isn't exploited. A company reported it to
> Oracle, the same happends at Adobe frquently, too.
It *is* being exploited. See http://blog.fireeye.com/research/2013/02/yaj0-yet-another-java-zero-day-2.html for example.
>
> > Then because Flash blocking will be considered as a war
> > declaration for websites that live with ads.
>
> So flash isn't blocked because it is used for adds. The few java-applets
> left that actually do useful stuff are.
>
> Anyway, who am I to complain.
Current statistics on this web page indicate that Java is very seldomly used on the web (about 0.2%), whereas Flash is more widely used (mostly for videos, e.g. youtube). See http://w3techs.com/technologies/overview/client_side_language/all

There _is_ a major difference between Flash and Java: Flash was designed to be a browser plugin. If it has bugs you could compromise it and do bad stuff inside the process. In doing so you have to work around the Flash process sandbox as well as all the OS/Compiler memory protections (DEP/ASLR) designed to make such compromises hard.
Java was designed as a system application programming environment, within which they created an "applet" sandbox that limits capabilities to a browser-safe subset. You could still have the kinds of memory corruption bugs Flash sometimes has, but most exploits find ways to confuse Java and sneak past those "you are an applet" limits. Once you do that the exploit is 100% reliable because it's not depending on memory corruption, and even cross-platform should the malware authors attach platform-specific payloads.

(In reply to Bill Martin from comment #61)
> So all and all, "FF 19.0 and Java 7/U15 plugin block is valid"?
Yes, all current versions of Java, including Java 7 U15 are click-to-play blocked in Firefox 17 and above.

My apologies for being a "cop" but this bug report is not the appropriate platform to have this discussion. If you are having problems related to plugin blocklisting please use support.mozilla.org. If you disagree or have feedback to share with regard to our current blocklisting policy please start a thread in the dev-security mailing list.
Thank you.

(In reply to almck55 from comment #65)
> I need my java script to be enabled I use it to play my pogo games
JavaScript and Java are two unrelated things.
The latest Java version is not CTP-blocked so please update: http://java.com

Question on the Java CTP block, especially about the Java 7 U5 block on Windows: It is intentional that (at least) this plugin was blocked as PluginVulnerableNoUpdate (that's the Firefox UI string, means no update link appears in the click-to-play UI itself). Or should it rather be blocked as PluginVulnerableUpdatable (as there is an update available for Java 7)? If yes, then I'll file a new bug on this.