Closed Bug 829111 Opened 11 years ago Closed 11 years ago

Blocklist with severity CTP for all versions of Java due to zero-day remote code execution vulnerability being actively exploited

Categories

(Toolkit :: Blocklist Policy Requests, defect, P1)

Product:
Toolkit
Component:
Blocklist Policy Requests
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: briansmith, Assigned: jorgev)

References

(
URL
)

Details

(Keywords: sec-critical, sec-vector) 

I am not sure if, because of bug 803152, we're already CTP'ing all versions of Java. If so, there may be nothing to do here.
Assignee: nobody → jorge
See https://wiki.mozilla.org/Blocklisting/PluginBlocks for our current state of plugin blocks. We have CTP blocks for Java 6 U33 - Java 6 U36 and Java 7 U7 - Java 7 U8. We would need to extend the blocks to cover the latest versions, or all versions.
See bug 829147 for recommendation to enable click to play for all versions of Java instead of blocklist.
No longer blocks: 829147
Keywords: sec-vector
Clarified summary to request "blocklist with severity CTP"
Summary: Blocklist all versions of Java due to zero-day remote code execution vulnerability being actively exploited → Blocklist with severity CTP for all versions of Java due to zero-day remote code execution vulnerability being actively exploited
(In reply to Michael Coates [:mcoates] from comment #3)
> See bug 829147 for recommendation to enable click to play for all versions
> of Java instead of blocklist.

To limit risk and necessary QA testing, I'd like to strongly suggest that we only CTP block those impacted versions that currently have no other blocks already in place.
what was the rationale for not blocking Java7 < update7 in bug 803152? are those versions soft blocked instead? They're certainly vulnerable.

At this point we need all versions of Java 7 <= update 10 blocked, either soft/hard blocked or CTP.

be careful with the regexp, update 10 is two digits now.
Severity: normal → critical
(In reply to Alex Keybl [:akeybl] from comment #6)
> (In reply to Michael Coates [:mcoates] from comment #3)
> > See bug 829147 for recommendation to enable click to play for all versions
> > of Java instead of blocklist.
> 
> To limit risk and necessary QA testing, I'd like to strongly suggest that we
> only CTP block those impacted versions that currently have no other blocks
> already in place.

Yes I'm good. So in summary, all versions of Java will be protected from either the old softblock (for old java versions) or the new Click To Play. This decision is based on testing and compatibility of CTP.
(In reply to Daniel Veditz [:dveditz] from comment #7)
> what was the rationale for not blocking Java7 < update7 in bug 803152? are
> those versions soft blocked instead? They're certainly vulnerable.

We didn't have the necessary internal testing and external feedback to be comfortable with CTP blocking all versions.

> At this point we need all versions of Java 7 <= update 10 blocked, either
> soft/hard blocked or CTP.

When this bug is completed, all released Java 6 and Java 7 versions will be either soft or CTP blocked.

So this bug basically represents CTP blocklisting 7u9, 7u10, 6u37, 6u38 for all platforms
(In reply to Alex Keybl [:akeybl] from comment #9) 
> So this bug basically represents CTP blocklisting 7u9, 7u10, 6u37, 6u38 for
> all platforms

If we do this, then we will have CTP blocks for 6u33 - 6u38 and 7u7 - 7u8, plus a softblock for 6u0 - 6u30, on 17 and above. All other Java blocks are limited up to Firefox 17, so they don't apply for 18 and above.

(In reply to Alex Keybl [:akeybl] from comment #9)
> When this bug is completed, all released Java 6 and Java 7 versions will be
> either soft or CTP blocked.

To accomplish this, we need to extend the CTP block in this bug to at least include 6u31, 6u32, and 7u0 - 7u6.
(In reply to Jorge Villalobos [:jorgev] from comment #10)
> If we do this, then we will have CTP blocks for 6u33 - 6u38 and 7u7 - 7u8

Sorry, I meant 7u7 - 7u10.
Assigning myself as QA contact. I can get on this as soon as 19b1 is out the door.
QA Contact: anthony.s.hughes
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #12)
> I can get on this as soon as 19b1 is out the door.

Correction, I can actually test this in parallel. No need to wait for QA to push this to staging.
(In reply to Alex Keybl [:akeybl] from comment #9)
> So this bug basically represents CTP blocklisting 7u9, 7u10, 6u37, 6u38 for
> all platforms

I extended the staged blocks to do this (and nothing more for now). We need QA at least for Java 7, making sure the blocks work for u9 and u10, given that the introduction of version 10 changes the regular expressions in a non-trivial way.
Keywords: qawanted
(In reply to Jorge Villalobos [:jorgev] from comment #10)
> (In reply to Alex Keybl [:akeybl] from comment #9)
> > When this bug is completed, all released Java 6 and Java 7 versions will be
> > either soft or CTP blocked.
> 
> To accomplish this, we need to extend the CTP block in this bug to at least
> include 6u31, 6u32, and 7u0 - 7u6.

I see the issue now. Let's discuss whether to CTP block these versions or bump some of the previous soft blocks up to include FF18. Perhaps CTP blocking is the lower risk option at this point.
(In reply to Jorge Villalobos [:jorgev] from comment #14)
> (In reply to Alex Keybl [:akeybl] from comment #9)
> > So this bug basically represents CTP blocklisting 7u9, 7u10, 6u37, 6u38 for
> > all platforms
> 
> I extended the staged blocks to do this (and nothing more for now). 

Just to confirm, we want to test Java 7u9, 7u10, 6u37, 6u38 are CTP blocked on staging in Firefox 17 and above? Also, do I need to wait for caching?
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #16)
> Just to confirm, we want to test Java 7u9, 7u10, 6u37, 6u38 are CTP blocked
> on staging in Firefox 17 and above? Also, do I need to wait for caching?

Correct on all accounts.
(In reply to Alex Keybl [:akeybl] from comment #15)
> Perhaps CTP blocking is the lower risk option at this point.

Yes, this avoids block overlaps or having to create new entries, and it offers a better user experience.
(In reply to Jorge Villalobos [:jorgev] from comment #10)
> To accomplish this, we need to extend the CTP block in this bug to at least
> include 6u31, 6u32, and 7u0 - 7u6.

The staged blocks have been updated to cover these older versions. After giving the cache an hour or so, this should be good for testing.
I tried to structure my testing so that it was as fast and broad as possible. I tested every affected version of Java once on a random platform and Firefox version, ensuring all platforms and all Firefox versions between 17.0 and 21.0a1 get some coverage. Here are my results.

CTP Blocked:
* Java 7u10 w/Firefox 18.0 on Windows 8
* Java 7u9 w/Firefox 17.0.1 on Mac OSX 10.7
* Java 7u6 w/Firefox 19.0b1 on Ubuntu 12.04
* Java 7u2 w/Firefox 18.0 on Ubuntu 12.04
* Java 7u1 w/Firefox 20.0a2 on Windows 8
* Java 7u0 w/Firefox 21.0a1 on Ubuntu 12.04
* Java 6u38 w/Firefox 18.0 on Windows 8
* Java 6u37 w/Firefox 17.0.1esr on Ubuntu 12.04
* Java 6u32 w/Firefox 19.0b1 on Windows 8
* Java 6u31 w/Firefox 20.0a2 on Ubuntu 12.04

Soft Blocked:
* Java 7u5 w/Firefox 17.0.2esr on Windows 8
* Java 7u4 w/Firefox 17.0.1 on Ubuntu 12.04
* Java 7u3 w/Firefox 17.0 on Windows 8

Please advise if more testing is required before pushing this live.
This looks good to me. There's overlap in Firefox 17 because the old softblocks and the new CTP blocks both apply for those versions, so you can get one or the other. 18 and above should only have CTP blocks.

I will push the updated blocks early tomorrow.
Keywords: qawanted
(In reply to Jorge Villalobos [:jorgev] from comment #21)
>> Soft Blocked:
>> * Java 7u5 w/Firefox 17.0.2esr on Windows 8
>> * Java 7u4 w/Firefox 17.0.1 on Ubuntu 12.04
>> * Java 7u3 w/Firefox 17.0 on Windows 8
>
> Firefox 18 and above should only have CTP blocks.

Since all the Softblocks appeared with Firefox 17 versions, did you want me to retest these Java versions against Firefox 18+?
I don't think that it is necessary to test this before pushing live, but it'd be useful to add it to the tests to run after I push today.
The blocks have been pushed live. Please given the cache some time and verify.
Status: NEW → RESOLVED
Closed: 11 years ago
Keywords: qawanted
Resolution: --- → FIXED
(In reply to Jorge Villalobos [:jorgev] from comment #25)
> Please given the cache some time and verify.

*give*
Thanks for the timely push all! Our users are safer now :)
Why did you block 6u38 and 6u37? They're both the same security baseline(1) and as far as I know different code base than 7 and hence not even mentioned on http://www.kb.cert.org/vuls/id/625617

Am I missing something? Is there any evidence of latest 6 updates also being affected that you could share, please?

Apologies on commenting on a resolved bug but I'm honestly curious in case you know better.

1 http://www.oracle.com/technetwork/java/javase/6u38-relnotes-1880997.html
(In reply to alex_mayorga from comment #28)
> Why did you block 6u38 and 6u37? They're both the same security baseline(1)
> and as far as I know different code base than 7 and hence not even mentioned
> on http://www.kb.cert.org/vuls/id/625617
> 
> Am I missing something? Is there any evidence of latest 6 updates also being
> affected that you could share, please?
> 
> Apologies on commenting on a resolved bug but I'm honestly curious in case
> you know better.
> 
> 1 http://www.oracle.com/technetwork/java/javase/6u38-relnotes-1880997.html

We are being extra cautious to ensure all users are protected in the event the scope of the vulnerability is larger than the initial reports have indicated. We are erring on the side of caution. However, click to play still enables users to access Java if they chose.
(In reply to Jorge Villalobos [:jorgev] from comment #25)
> The blocks have been pushed live. Please given the cache some time and
> verify.

Verified the CTP/Soft live blocks are working as reported in comment 20. I also checked that the Softblocks for Java 7u{3,4,5} in Firefox 17 are indeed CTP blocked in Firefox 18+.
Status: RESOLVED → VERIFIED
Keywords: qawanted
Oracle has released a fix[1], 7u11, but seems like this block is overreaching based on user comments[2] and still blocking when updated.

Should this be reopened?

1 https://blogs.oracle.com/security/entry/security_alert_for_cve_2013
2 https://blog.mozilla.org/security/2013/01/11/protecting-users-against-java-vulnerability/comment-page-1/#comment-110981
(In reply to alex_mayorga from comment #32)
> Oracle has released a fix[1], 7u11, but seems like this block is
> overreaching based on user comments[2] and still blocking when updated.
> 
> Should this be reopened?
> 
> 1 https://blogs.oracle.com/security/entry/security_alert_for_cve_2013
> 2
> https://blog.mozilla.org/security/2013/01/11/protecting-users-against-java-
> vulnerability/comment-page-1/#comment-110981

The blog comments might be related to bug 820759 and 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005410 which first appeared in Java 7u10 (fixed in 7u12)

The Java 7 Update 11 release notes, http://www.oracle.com/technetwork/java/javase/7u11-relnotes-1896856.html refer to 8005410 under  Known Issues, 
Area: deploy Synopsis: Problems with Registration of Plugin on Systems with Stand-alone Version of JavaFX Installed
Hello, Could the Java 6u38 plugin please be unblocked? It seems that only Java 7u* till 7u11 are vulnerable for this exploit. The exploit doesn't have effect on Java 6 versions.

https://blogs.oracle.com/security/entry/security_alert_for_cve_2013
Echoing the request in Comment 34. Java 6u38 is the current version of Java 6 and we need to have it until Oracle compels everyone to move to Java 7.
(In reply to RoestVrijStaal from comment #34)
> Hello, Could the Java 6u38 plugin please be unblocked? It seems that only
> Java 7u* till 7u11 are vulnerable for this exploit. The exploit doesn't have
> effect on Java 6 versions.
> 
> https://blogs.oracle.com/security/entry/security_alert_for_cve_2013

are you unable to click through and activate the Java plugin explicitly ?

(same question for Scott's request in comment 35)
On applets that show up discretely on the screen, yes. However, some (e.g., Cisco's SSL VPN) don't have a place to do so. Nor does Oracle's Java verification page:

http://java.com/en/download/installed.jsp?detect=jre

In the case of Oracle, one can click on the plugin icon to the left of the URL to choose to activate the plugin. It also has a way to whitelist the site for future use. That may be sufficient for the next month or so, when Oracle starts forcing Java 7, but from a user-experience standpoint, it's less than optimal.
Reopening as there seems to be something not quite right with this block.

I've installed Java 7u11 which is detected by Nightly in about:plugins like:

Java Deployment Toolkit 7.0.90.5

    File: npdeployJava1.dll
    Version: 10.9.2.5
    NPRuntime Script Plug-in Library for Java(TM) Deploy

Yet if I go to http://www.java.com/en/download/installed.jsp?detect=jre the page prints out "No working Java was detected on your system. Install Java by clicking the button below."

If I go to http://www.javatester.org/version.html "Install Missing Plugins..." button offers me to install Java Runtime Environment 1.7 u10 which I believe is buggy behavior so I've filed bug 830810.

Also the block should be lifted for 6u37 and 6u38.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Alex, the Java Deployment Toolkit is a separate thing from Java itself.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Mr. Smedberg,

Bottom line, Firefox users with Java 7u11, 6u37 and 6u38 installed are still prevented from using it even when these are perfectly safe.

Is there a bug on file for that?
Issues of Java not working with Java 7u11 installed should be filed as a separate bug (Core/Plug-ins).

6u37 and 6u38 are still intentionally blocked, and filing a bug for that issue would not be useful.
(In reply to alex_mayorga from comment #40)
> Bottom line, Firefox users with Java 7u11, 6u37 and 6u38 installed are still
> prevented from using it even when these are perfectly safe.

I'll just point this out since it's clear that most people are deceived by Oracle's alleged Java 7u11 "fix", which is not a proper fix.

All Oracle did was set the default security level higher but did absolutely nothing to fix the underlying vulnerability: http://betanews.com/2013/01/14/java-7-update-11-security-patch-fixes-nothing/
(In reply to IU from comment #42)
> (In reply to alex_mayorga from comment #40)
> > Bottom line, Firefox users with Java 7u11, 6u37 and 6u38 installed are still
> > prevented from using it even when these are perfectly safe.
> 
> I'll just point this out since it's clear that most people are deceived by
> Oracle's alleged Java 7u11 "fix", which is not a proper fix.
> 
> All Oracle did was set the default security level higher but did absolutely
> nothing to fix the underlying vulnerability:
> http://betanews.com/2013/01/14/java-7-update-11-security-patch-fixes-nothing/

The default security level change was in addition to the fix for the vulnerability, see:
http://www.oracle.com/technetwork/java/javase/7u11-relnotes-1896856.html
(In reply to John Schoenick [:johns] from comment #43)
> The default security level change was in addition to the fix for the
> vulnerability, see:
> http://www.oracle.com/technetwork/java/javase/7u11-relnotes-1896856.html

Why the refusal to lift the block on 7u11 then?

Why block 6u37 and 6u38 if they're not even affected?

This would just annoy and drive away Firefox users IMHO.
(In reply to alex_mayorga from comment #44)
> Why the refusal to lift the block on 7u11 then?

7u11 shouldn't be blocked. If it is for you, see comment #41 on what to do about it.
(In reply to Jorge Villalobos [:jorgev] from comment #45)
> (In reply to alex_mayorga from comment #44)
> > Why the refusal to lift the block on 7u11 then?
> 
> 7u11 shouldn't be blocked. If it is for you, see comment #41 on what to do
> about it.

Media reports say a 0day in 7u11 is already for sale : http://thenextweb.com/insider/2013/01/16/less-than-24-hours-after-last-patch-criminals-were-selling-a-new-java-exploit-for-5000-per-buyer/
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #22)
> (In reply to Jorge Villalobos [:jorgev] from comment #21)
> >> Soft Blocked:
> >> * Java 7u5 w/Firefox 17.0.2esr on Windows 8
> >> * Java 7u4 w/Firefox 17.0.1 on Ubuntu 12.04
> >> * Java 7u3 w/Firefox 17.0 on Windows 8
> >
> > Firefox 18 and above should only have CTP blocks.
> 
> Since all the Softblocks appeared with Firefox 17 versions, did you want me
> to retest these Java versions against Firefox 18+?

How do I get Java 7u3 w/Firefox 17.0 on Windows 7?
(In reply to Carlos E. Backes from comment #47)
> How do I get Java 7u3 w/Firefox 17.0 on Windows 7?

My apologies but neither will I advise you on how to install vulnerable software, nor is bugzilla the right place to get this type of question answered. Sorry.
See http://seclists.org/fulldisclosure/2013/Jan/142

"[SE-2012-01] Java 7 Update 11 confirmed to be vulnerable"
Though I updated to 7u11, I also observed one thing that despite of these updates, Java plugin for Mozilla browser does not get updated since 7u7 indicating it is vulnerable.
Java Plugin 7 update 11 and lower (click-to-play), Windows has been blocked for your protection.
When viewing a Web page that uses Java, the user now gets a gray box with a Lego graphic and the caption "Click here to activate plugin."  Clicking in that area does indeed activate Java.  

However, it is now impossible to verify installation of Java at <http://www.java.com/en/download/installed.jsp>.  Does that apply to ALL versions of Java, including future versions?  Or is this a problem only for Java 7u11 and earlier versions?
Excuse me as I just registered. I have personal issues with your decision to block this app. I do not use the higher versions of Firefox. I can handle the security problems that may or may not exist. I understand I agreed to the TOS. but and I sat I see where issue has been resolved. What happened to Mozilla's promise to deliverer a better browser? I. E. has way too many attackers and we love your add on....but now again maybe it is time for all parties to sit down and work out some sort of deal to work with each other instead of fighting against the solution. I am a 3rd party Electrical Inspector. We leave the choice up to the client (we in this statement) and then make everything fair to all. It works in my profession.
(In reply to David E. Ross from comment #52)
> However, it is now impossible to verify installation of Java at
> <http://www.java.com/en/download/installed.jsp>.

It should be possible to do so. Whenever a plugin is blocked on a page, you should see a little icon to the left of the URL bar. Clicking on it and following the indications should allow you to enable the plugin for that site.

> Does that apply to ALL
> versions of Java, including future versions?  Or is this a problem only for
> Java 7u11 and earlier versions?

At the moment the block is limited to 7u11 and earlier, but it may be extended to all versions of Java.
(In reply to Fran from comment #53)
> We leave the choice up to the client (we in this statement) and
> then make everything fair to all. It works in my profession.

We are leaving the choice to the user. You can enable applets whenever you need them. They're just disabled by default so that you don't get compromised when visiting a compromised or malicious site.
Sorry guys, I hate to say that I've had to go back to IE :-(  I have to run many on-line chemical searches, and to CTP the java box and re-load the applet every single time I go back from the results page and return to the query page is just taking far to much extra time. There needs to be a way for a user to "whitelist" a site or for Firefox to remember that I've just CTP that applet 30 secs ago.
http://www.oracle.com/technetwork/topics/security/alert-cve-2013-0422-1896849.html - is this oracle confirming they have fixed the issue.
(In reply to Ron Jones from comment #56)
> Sorry guys, I hate to say that I've had to go back to IE :-(  I have to run
> many on-line chemical searches, and to CTP the java box and re-load the
> applet every single time I go back from the results page and return to the
> query page is just taking far to much extra time. There needs to be a way
> for a user to "whitelist" a site or for Firefox to remember that I've just
> CTP that applet 30 secs ago.

Hi Ron, when going to a page that has plugins blocked with CTP, you can click the small blue block that appears to the left of the URL in the address bar and select 'always allow for this site' which should give you the site whitelist you are looking for.
(In reply to Ian Melven :imelven from comment #58)

Hi Ron, when going to a page that has plugins blocked
> with CTP, you can click the small blue block that appears to the left of the
> URL in the address bar and select 'always allow for this site' which should
> give you the site whitelist you are looking for.

Thanks for that - some else sent me an e-mail as well. All is now well - it was worth posting a comment! Learn something new every day!
Finally got my account setup to complain about this bug and its "solution", refreshed the page, and -- blammo -- there was a solution on how to white-list the site(s) I needed.  Woot!  Thanks for all the commenters who took the time to write-in and thanks to all the devs who have worked on fixing this bug.

This bug / behavior is / was a show-stopper for me.  It was preventing me from getting my work done.  I use a browser-launched meeting tool several times a week (GoTo Meeting) and it would no longer launch with this bug / "solution".

FWIW -- The current user interaction to "whitelist" a site is totally and utterly NON-OBVIOUS.  I never even noticed something blinking up in the address bar.  I consider this "work-around" a major usability fail for the Firefox team.  If I hadn't taken the time to Google this, and track it down via Firefox's "Addons" menu, and read this bug thread, I wouldn't have known how to do this.  In fact, before I even got this far, I simply set up my default browser to be Chrome.

Frankly, at this point, I'm not sure if I'm going to switch back to Firefox being my default browser.  I've been a Firefox fan for years (back since the 2.x days), but this is the 2nd or 3rd time in the last year where stuff like this has made Firefox harder to use (from my standpoint).  Most of these issues have been related to Java support / integration too.  I understand the need to protect most users from themselves and the big bad wolves on the internets, but please give us more experienced users (who generally know what we are doing), a simple, accessible, documented way to get around stuff like this.
I raised bug 833364 with my concerns about blocking 6u38. This has been
marked as a duplicate of this bug and the comment was made "please comment in
bug 829111 as to keep all information in one central bug". Here is what I said
in Bug 833364.

Bug 833364 - Mozilla blocklisting policy ignored when blocking java 6u38

I use Java version 6u38 and have just updated from Firefox 10.0.12esr to 17.0.2esr

I went to the "Add-ons Manager" and see it states that
"Java(TM) Platform SE 6 U38 is known to cause security or stability issues."

I am unaware of any reported security issues for 6u38 (although I am aware
that security issues have been reported for 7u11).

I have found the Mozilla security blog and, in the comments, when "skeptic"
asks about blocking of 6u38, "mcoates" indicates that Mozilla know of no
reported security issues with 6u38 (the post reads "We are being extra cautious to ensure all users are protected in the event the scope of the vulnerability is larger than the initial reports have indicated. We are erring on the side of caution.").
See https://blog.mozilla.org/security/2013/01/11/protecting-users-against-java-vulnerability/

I also found Mozilla's blocklisting policy. Blocklisting reasons include
"Critical security vulnerabilities". However the policy also states "Blocking
third-party software is a sensitive issue that must be carefully considered
in every case. We must be certain that the issue at hand is so great that it
outweighs the user's choice to install the software, the utility it provides,
and the vendor's freedom to distribute and control their software."
See https://wiki.mozilla.org/Blocklisting

As Mozilla are not certain 6u38 has a security issue, blocking it is against
Mozilla's blocklisting policy.

I also think blocking 6u38 without there being a known security issue is a
BAD idea. Having researched the reason for blocking 6u38, I've added a
permanent exception for 6u38 and I expect other people have or will do
the same. The means that if a security issue is later actually found in
6u38, Mozilla can't warn us by added a block when the security issue is found.
See Aesop's Fable "The Boy Who Cried Wolf" http://en.wikipedia.org/wiki/The_Boy_Who_Cried_Wolf
(In reply to alex_mayorga from comment #32)
> Oracle has released a fix[1], 7u11, but seems like this block is
> overreaching based on user comments[2] and still blocking when updated.
> 
> Should this be reopened?
> 
> 1 https://blogs.oracle.com/security/entry/security_alert_for_cve_2013
> 2
> https://blog.mozilla.org/security/2013/01/11/protecting-users-against-java-
> vulnerability/comment-page-1/#comment-110981

Agreed that this block is overreaching.
It's great that there is so much interest in this topic. However, this bug is not the best place for discussion. I would suggest posting to dev-security-policy@lists.mozilla.org (although that may not be the best list as this issue is a mix of security, policy, and plugins - if someone on that list has a strong opinion, they'll no doubt point you to the right place).
If we're going to discuss the UI of the click-to-play feature, let's discuss in mozilla.dev.apps.firefox.  That's not really a matter of security policy ;-)
Why do I not see an entry for this in "Blocked Add-ons" at <https://addons.mozilla.org/en-US/firefox/blocked/> or <https://addons.mozilla.org/en-US/seamonkey/blocked/>?
(In reply to David E. Ross from comment #66)
> Why do I not see an entry for this in "Blocked Add-ons" at
> <https://addons.mozilla.org/en-US/firefox/blocked/> or
> <https://addons.mozilla.org/en-US/seamonkey/blocked/>?

Because you have to scroll down the list till October 30, 2012…!
According to those pages, "Java Plugin 6 updates 38" and "Java Plugin 7 update 11" have been blocklisted on that date. IMHO, this is simply illogic and misleading since on that date they hadn't even been released!

Moreover, the "View block request." link in the "Java Plugin 7 update 11 and lower (click-to-play), Mac OS X" page[1] links to the wrong bug (bug 803152). As a consequence, reading bug 803152 I had an hard time trying to understand why Java Plugin 7 update 11 was still blocked, before founding this bug.

The links in the other operating systems pages, "Java Plugin 7 update 11 and lower (click-to-play), Windows"[2] and "Java Plugin 7 update 11 and lower (click-to-play), Linux"[3], are OK and correctly point to this bug.

[1] <https://addons.mozilla.org/en-US/seamonkey/blocked/p180>
[2] <https://addons.mozilla.org/en-US/seamonkey/blocked/p182>
[3] <https://addons.mozilla.org/en-US/seamonkey/blocked/p184>
i've had a great idea...
STOP updating ffox every 5 minutes, and thereby creping on loads of standard add-ins. just do it once every year.
this block has been p1551ng for 3 months - craaaaazy
(In reply to Andrea Govoni from comment #67)
> (In reply to David E. Ross from comment #66)
> > Why do I not see an entry for this in "Blocked Add-ons" at
> > <https://addons.mozilla.org/en-US/firefox/blocked/> or
> > <https://addons.mozilla.org/en-US/seamonkey/blocked/>?
> 
> Because you have to scroll down the list till October 30, 2012…!
> According to those pages, "Java Plugin 6 updates 38" and "Java Plugin 7
> update 11" have been blocklisted on that date. IMHO, this is simply illogic
> and misleading since on that date they hadn't even been released!
> 
> Moreover, the "View block request." link in the "Java Plugin 7 update 11 and
> lower (click-to-play), Mac OS X" page[1] links to the wrong bug (bug
> 803152). As a consequence, reading bug 803152 I had an hard time trying to
> understand why Java Plugin 7 update 11 was still blocked, before founding
> this bug.

That's a consequence of modifying existing blocks instead of creating new ones. You have a good point there, and we should sort them by last modification date rather than creation date. I'll file a bug for that. I can also update them so they show the latest relevant bug number, though ideally we should show all of them.
Full agreement with #61 and #62.  My issue is I'm using a web based console switch to do my job and CTP doesn't work and I can't find any way to get my Dominion SX32 to connect.  I had an FE come into my cubicle after I had downed a server via ssh yesterday and I needed to reboot it from the console.  First I enabled Java via QuickJava and next I see CTP for the first time.  I CTP and then login, but no matter what I do I never get to the console of the POWERED OFF remote corporate server server.  Not cool, not funny.  Since the FE needs this, and needs this now, and I don't know it I have a Java or Firefox issue I do the one thing that never fails, I switch to my (always running) W98 VM and use the last supported versions - Firefox 2.0.0.2 and Java 1.5.22 - to immediately get the server up.  IE probably would have worked too. I'm reading the previous issues and seeing references to a blue whitelist box that I don't have - just a red lego.  Right now I want to keep my Java 6U38 until Oracle puts out a better 7.x, and I need my console.  How do I kill CTP?
Paul I'm sorry but we can not provide user support on bugzilla. This is a bug tracker. If you need help with your issue, please visit https://support.mozilla.org/. It provides a knowledge database for common problems as well as forums with user-to-user support.
(In reply to Andreas Wagner [:TheOne] from comment #71)
> Paul I'm sorry but we can not provide user support on bugzilla. This is a
> bug tracker. If you need help with your issue, please visit
> https://support.mozilla.org/. It provides a knowledge database for common
> problems as well as forums with user-to-user support.

OK.  It's understood that going to the Dominion and using CTP to log in OK still leaves you with a broken interface that won't connect, and this is different from editing out the Java 6 blockID's from the blocklist.xml - which lets you log in without CTP and then works correctly?  To rephrase, CTP prevents me from doing my job while editing the blocklist.xml [and toggling extentions.blocklist.enabled] restores the lost functionality.
(In reply to Paul Kary from comment #72)
> OK.  It's understood that going to the Dominion and using CTP to log in OK
> still leaves you with a broken interface that won't connect, and this is
> different from editing out the Java 6 blockID's from the blocklist.xml -
> which lets you log in without CTP and then works correctly?  To rephrase,
> CTP prevents me from doing my job while editing the blocklist.xml [and
> toggling extentions.blocklist.enabled] restores the lost functionality.

You should be able to click on the plugin icon in the URL bar and select 'always activate for this site' to override the CTP blocking. Discussion on whether or not blocking should be active belongs on the mailing lists.
It appears this broke something.

I am running ff 18.0.1 on win xp
under addons - plugins, I have Java Platform SE 7 U11 10.11.2.21 enabled, showing the stripped warning.

Even though enabled, it still blocks java from running.

On ebay, they use java to print USPS postage via Pitney Bowles. I select my printer, click "Print Sample Label" and nothing happens. It has been this way for over a week now. Not sure how long before that.

At first I thought it was ebay/pitney bowles causing the problem again as they are struggling converting to a cloud based utility. But I have now confirmed it is not them.

I opened google chrome to the same ebay page and was able to print the label with no problem. It is something in ff that is broken now.

This should be reopened until it is fixed.
(In reply to BugMagnet from comment #74)
> I am running ff 18.0.1 on win xp
> under addons - plugins, I have Java Platform SE 7 U11 10.11.2.21 enabled,
> showing the stripped warning.
> 
> Even though enabled, it still blocks java from running.

Sure?
https://support.mozilla.org/en-US/kb/how-to-use-java-if-its-been-blocked
I am fairly sure.

I was past that step. When the ebay [print shipping label] page opened, it had the icon and warning that java was blocked. I clicked to activate. Java opened, an image of the label appeared with options to select the printer, print sample label, print actual label. I first set the printer, then clicked [print sample label] - nothing happened. I changed the printer from my label printer to my old hp laserjet and tried again ...nothing.

I copied the URL for that ebay page, entered it into google chrome and it gave a similar [Java needs your permission to run] challenge. I gave permission to run once, the label image appeared and when I clicked to print a sample to my label printer, it did it without issue.

I went back to FF and can't get it to work. JAVA is enabled in Addons-plugins. and I gave permission to run. It seemed to run, partially, since it produces the label image and dialog options, but it won't send to any of my printers.

It worked fine a few weeks back. something has been broken since. Could it be that the ebay/pitney bowles code handles java in chrome differently than from java from firefox? I don't know.  All I do know is that chrome prints the labels and firefox doesn't. And FF is my preferred browser by far. I only use others when forced to.
(In reply to Jorge Villalobos [:jorgev] from comment #69)
> That's a consequence of modifying existing blocks instead of creating new
> ones. You have a good point there, and we should sort them by last
> modification date rather than creation date. I'll file a bug for that.

Thank you.

> I can
> also update them so they show the latest relevant bug number, though ideally
> we should show all of them.

The Java Plugin 7 update 11 and lower Mac OS X block[1][2] is still showing the wrong bug number, though, while the Windows and Linux blocks correctly link to this bug.
Could you fix it or should I file a new bug for that?


[1] <https://addons.mozilla.org/en-US/seamonkey/blocked/p180>
[2] <https://addons.mozilla.org/en-US/firefox/blocked/p180>
Re comment #69:  What is the bug number?
(In reply to David E. Ross from comment #78)
> Re comment #69:  What is the bug number?

The one to sort the blocks by last modification date filed by Jorge is bug 834232.
https://support.mozilla.org/en-US/kb/how-to-use-java-if-its-been-blocked

Thank you for this.  LEFT click the RED icon....  I did an exhaustive search of the tools option and other stuff before removing the block from blocklist.xml.  This DOES permit the Dominion to connect to its targets, which CTP does NOT.
(In reply to Andrea Govoni from comment #77)
> The Java Plugin 7 update 11 and lower Mac OS X block[1][2] is still showing
> the wrong bug number, though, while the Windows and Linux blocks correctly
> link to this bug.
> Could you fix it or should I file a new bug for that?

It's fixed now, thanks.
Depends on: 836202
Do this apply to Java 7u13?
Depends on: 837567
(In reply to David E. Ross from comment #82)
> Do this apply to Java 7u13?

Java is only blocked up to 7u11 at present.
(In reply to Jorge Villalobos [:jorgev] from comment #83)
> (In reply to David E. Ross from comment #82)
> > Do this apply to Java 7u13?
> 
> Java is only blocked up to 7u11 at present.

How about landing bug 837240 and be done with it all? =)
Because I cannot update Java, I cannot play games on this website that I am paying over $40 for. Thanks, Firefox, you officially suck.
I see the status says resolved fixed, yeah, it's not. I cannot play games I pay money for. What a rip off.
(In reply to kittykatsrule97 from comment #85)
> Because I cannot update Java, I cannot play games on this website that I am
> paying over $40 for. Thanks, Firefox, you officially suck.
> I see the status says resolved fixed, yeah, it's not. I cannot play games I
> pay money for. What a rip off.

Please see https://support.mozilla.org/en-US/kb/how-to-use-java-if-its-been-blocked
Due to bug 1222557, this block had to be split in two:

Java Plugin 7 update 10 and lower (click-to-play), Mac OS X
https://addons.mozilla.org/blocked/p180

Java Plugin 7 update 11 (click-to-play), Mac OS X
https://addons.mozilla.org/blocked/p1052
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.