Closed Bug 636633 Opened 13 years ago Closed 11 years ago

Arbitrary Code Execution in Java Deployment Toolkit plugin

Categories

(Toolkit :: Blocklist Policy Requests, defect)

x86
Windows 7
defect
Not set
major

Tracking

()

RESOLVED FIXED
Tracking Status
firefox8 - ---
firefox9 - ---
firefox10 - ---
firefox11 - ---

People

(Reporter: neal, Assigned: jorgev)

References

()

Details

(Keywords: sec-vector, Whiteboard: [sg:vector-critical] [CVE-2011-3516])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13

I sent a report to Oracle just a few minutes ago, but since the vulnerability affects Firefox by way of an insecure plugin, I thought I should report it here as well. I should note that I'm not aware of anyone actively exploiting this vulnerability.

--- 

I'm writing to report an arbitrary code execution vulnerability in the Java Deployment Toolkit Plugin (according to Firefox, Java Deployment Toolkit 6.0.240.7). This vulnerability has been tested and confirmed to work in Firefox 3.5 on Windows 7 (both 64-bit and 32-bit). The root cause is an insufficient amount of validation on executables downloaded by the plugin.

The details are as follows:
- The plugin allows Javascript in the browser to trigger an installation by calling an installLatestJRE() method.
- When a call to installLatestJRE() is made, the plugin makes a request to java.sun.com over HTTP to fetch the installer, which is an EXE.
- In Internet Explorer, the plugin appears to validate the signature on the file itself, which limits what files can be executed. It displays an error message when it does not detect a valid signature.
- In Firefox, however, the downloaded EXE appears to be run without any signature validation (unsigned executables and executables signed by other companies are run without prompt).
- As a result, a malicious attacker can cause a user to download and execute an arbitrary executable under certain conditions (the attacker must be able to cause the user's browser to execute JavaScript, and the attacker must be able to substitute their own executable for the Java installer: this requires an attacker on the same network with some degree of control over DNS and/or actual web traffic).

To replicate this easily in a test environment, you can manually set the IP for java.sun.com in your HOSTS file so that it points to a local webserver. You can then configure that webserver so that a request to http://java.sun.com/webapps/download/AutoDL serves up an executable.

I have a demonstration set up at 173.203.112.165 which serves up calc.exe (the Windows calculator program). You can trigger it by adding the following line to your HOSTS file:
173.203.112.165    java.sun.com
and browsing to the following URL, which triggers a call to installLatestJRE():
http://nealpoole.com/poc/f565016a6543a455d191a863a0d61d30.html

Note that by using my demonstration (as opposed to setting up your own), you would be allowing my webserver to execute an arbitrary EXE on your computer. I promise not to take advantage of that situation, but if you are uncomfortable with that idea, you are more than welcome to set up your own test environment.

Reproducible: Always

Steps to Reproduce:
1. Install the JRE. Ensure the Java Deployment Toolkit plugin is installed.
2. Edit your HOSTS file so that java.sun.com points to a webserver controlled by you (173.203.112.165 will load calc.exe, you could also set up a webserver on 127.0.0.1 and serve your own executable)
3. Browse to http://nealpoole.com/poc/f565016a6543a455d191a863a0d61d30.html in Firefox, which triggers the download and installation. Your executable should run.
Assignee: nobody → morgamic
I need to update this report a little bit ;-)

1. I moved my demonstration to a new IP: 173.255.227.177
2. The demonstration now downloads a copy of the installer for Notepad++ instead of calc.exe.
3. The code only runs without prompting when UAC is disabled. If UAC is enabled, the user is prompted to run an executable named JREInstallVERSION.exe (ie: JREInstall160_24.exe).
4. Oracle has told me that they aim to release a fixed version in the October Critical Patch Update for Java.
The October 2011 Critical Patch Update was released. That means the latest versions of Java 6 and Java 7 are no longer vulnerable (Java 7 was patched silently earlier in the year). I've written a little bit about the vulnerability on my blog: https://nealpoole.com/blog/2011/10/java-deployment-toolkit-plugin-does-not-validate-installer-executable/
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [sg:critical]
This has been sitting for a looong time, what's holding us up here?
Whiteboard: [sg:critical] → [sg:vector-critical]
Is a block necessary here? If so, which versions of the plugin should be blocked?
Assignee: morgamic → jorge
https://nealpoole.com/blog/2011/10/java-deployment-toolkit-plugin-does-not-validate-installer-executable/

"The Java Deployment Toolkit Plugin v6.0.240.7 and below for Firefox and Google Chrome can be used to download and run an improperly signed executable on a target’s system. UAC, if enabled, will prompt the user before running the executable. This vulnerability has been tested and confirmed to exist on Windows 7, both 32-bit and 64-bit. It was fixed in Java 7 and Java 6 Update 29. This issue has been assigned CVE-2011-3516."
Blocking this is tricky since we need to use regular expressions, per bug 558584 comment 16. Is there a listing of all version numbers that have been released? It's easier to just enumerate those vulnerable versions not covered in bug 558584.
Keywords: sec-vector
Keywords: sec-other
Is this still a security concern?
Flags: needinfo?(dveditz)
Yes, people running the old versions are still at risk. We should just blocklist the Java Deployment Toolkit Plugin entirely (click to play) since it's not used to run Java applets (that's a separate Java Platform plugin) and is generally unnecessary.
Flags: needinfo?(dveditz)
Are we okay with blocking all versions of the Java Deployment Toolkit? It seems harmless enough to do this.
Flags: needinfo?(release-mgmt)
Anthony, we need the about:plugins info for the Java Deployment Toolkit in the 3 major platforms. Same as with the others, latest versions and a few old ones so I know what to use for the blocklist filters.
Keywords: qawanted
QA Contact: anthony.s.hughes
(In reply to Jorge Villalobos [:jorgev] from comment #10)
> Anthony, we need the about:plugins info for the Java Deployment Toolkit in
> the 3 major platforms. Same as with the others, latest versions and a few
> old ones so I know what to use for the blocklist filters.

Okay, this will take some time. How soon do you need this done by?
It's not urgent (this bug is pretty old). Within a couple of weeks is good for me, thanks.
(In reply to Jorge Villalobos [:jorgev] from comment #9)
> Are we okay with blocking all versions of the Java Deployment Toolkit? It
> seems harmless enough to do this.

Sounds good to us, with QA verification.
Flags: needinfo?(release-mgmt)
Here is the info for the versions we were able to find:
https://wiki.mozilla.org/QA/Plugins/About:Plugins#Oracle_Java_Development_Kit
Keywords: qawanted
Anthony: That doesn't look quite right. This bug is about the Java Deployment Toolkit (Java DT, http://www.java.com/en/download/faq/deployment_toolkit.xml), not the Java Development Kit (JDK).

Java 7u25 yields the following Java Deployment Toolkit plugin info on Windows for me:

Java Deployment Toolkit 7.0.250.16

    File: npDeployJava1.dll
    Version: 10.25.2.16
    State: Enabled
    NPRuntime Script Plug-in Library for Java(TM) Deploy
Sorry, I wasn't clear that was what you were looking for. I'll work on getting that information for you over the coming days.
Okay information is now available:
https://wiki.mozilla.org/QA/Plugins/About:Plugins#Oracle_Java_Deployment_Toolkit

Apologies again for the delay and confusion.
Block is staged now for all versions of this plugin. Please give it a quick test: https://addons-dev.allizom.org/firefox/blocked/p361
Keywords: qawanted
(In reply to Jorge Villalobos [:jorgev] from comment #18)
> Block is staged now for all versions of this plugin. Please give it a quick
> test: https://addons-dev.allizom.org/firefox/blocked/p361

What can we use to confirm the plug-in is being blocked? Is the STR and server in comment 0 still relevant and available?
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #19)
> (In reply to Jorge Villalobos [:jorgev] from comment #18)
> > Block is staged now for all versions of this plugin. Please give it a quick
> > test: https://addons-dev.allizom.org/firefox/blocked/p361
> 
> What can we use to confirm the plug-in is being blocked? Is the STR and
> server in comment 0 still relevant and available?

Hmm, good point. I don't know if those are still valid. If we can't find some easy way to test this, I'll just move forward with the block.
Would you like me to set up a working proof of concept again?
We don't need an exploit PoC, just something that we can use to verify the block is working or not. If you can give us that, that would be most excellent :).
Easy enough to do!

http://sandboxing.me/poc/f565016a6543a455d191a863a0d61d30-2.html

Requires JavaScript to be enabled. It will say either Yes or No depending on whether the plugin is enabled.
Thanks, I'll try to have this tested and signed off by tomorrow.
Does not appear to be working. I tested with Firefox 25.0a1 and JDT 7.0.250.16 (Java 7u25) on Windows XP. Before pinging the blocklist the test page displays "YES". After pinging the staged blocklist the test page still displays "YES".

I see the following in my profile blocklist.xml following the ping to staging:
> <pluginItem blockID="p361">
>   <match name="filename" exp="npdeployJava1\.dll"/>
>   <versionRange severity="0" vulnerabilitystatus="2"/>
> </pluginItem>

Note about:plugins shows:
> Path: C:\WINDOWS\system32\npDeployJava1.dll

I'm not sure if the blocklisting mechanism is case sensitive but that might be why this is failing.
I just updated the staged block so that it supports the upper case and lower case D in the file name. Please try again.
Testing is now completed on staging with no issues found. Please push this live.
Keywords: qawanted
Blocked: https://addons.mozilla.org/firefox/blocked/p428
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Roger Lewis, is there an Oracle advisory for this bug now, and is it fixed in the latest Java version? Can we un-hide this bug?
Flags: needinfo?(roger.lewis)
Benjamin, The advisory is under CVE-2011-3516, found http://www.oracle.com/technetwork/topics/security/javacpuoct2011-443431.html which went out with the October 2011 release.
Flags: needinfo?(roger.lewis)
Group: client-services-security
Whiteboard: [sg:vector-critical] → [sg:vector-critical] [CVE-2011-3516]
Hello, Team,

JFYI 7u51 is here and I didn't found anything about it in the Oracle's allerts. Either somebody did?

Just curious... Is that so nobody thinks about a two simple and clear things?
1. this "bug" looks, er... well, a bit ancient.
2. this big fat red warning and explanation page that points out to (1) constantly shames Oracle and moreover IS a shameless LIE.
(In reply to vitar from comment #32)
> Hello, Team,
> 
> JFYI 7u51 is here and I didn't found anything about it in the Oracle's
> allerts. Either somebody did?
> 
> Just curious... Is that so nobody thinks about a two simple and clear things?
> 1. this "bug" looks, er... well, a bit ancient.
> 2. this big fat red warning and explanation page that points out to (1)
> constantly shames Oracle and moreover IS a shameless LIE.
Hi,

is there a reason to block an application if the status is resolved fixed?
I have really trouble that I'm not able to use secure_auth with firefox because of this block.

Thanks for an answer
Flags: needinfo?(anthony.s.hughes)
(In reply to Martin Greulach from comment #33)

Please open a new thread on support.mozilla.org and reference this bug report.
Flags: needinfo?(anthony.s.hughes)
https://support.mozilla.org/questions/983583

What kind of support are we supposed to provide for this situation? No Click-to-Play prompt, no way to disable Click-to-Play, original issue may be long patched by now. What else is there to do but disable the entire blocklist and punch a giant security in Firefox for the sake of this one plug-in?
Flags: needinfo?(anthony.s.hughes)
Please wait for a response from someone at Mozilla on that thread. I will not respond to further need-info requests on this bug.
Flags: needinfo?(anthony.s.hughes)
(In reply to Gingerbread Man from comment #35)
> https://support.mozilla.org/questions/983583
Sorry for reply here but I'm too lazy to register around every corner. Anyway glad been to heat Team's brains a bit :-)

And sorry again but this "Chosen Solution" (it's the best up to now, isn't it) looks the same stupid^W strange as a wide-known MS Outlook "security" (unconditional blocking of attachments by extension) or even worse. AFAIR blocklisting been a versions/bulds based. Pity I was wrong.
Ok so what is it with this bug or whatever,  just today I cant get into http://www.skyviewcafe.com/skyview.php,it used to give me the option to proceed at my own risk, now cant even do that.
After activating Java at http://www.skyviewcafe.com/skyview.php I see an "Application Blocked" dialog.  This Java message has nothing to do with the Java Deployment Toolkit.  See these Java Help pages:
http://www.java.com/en/download/help/appsecuritydialogs.xml
http://www.java.com/en/download/help/java_blocked.xml
Wow, thanks a lot for your fast reply, did what u suggested and it worked.
Please don't permanently block this. My children's Virtual Academy uses it for Blackboard Collaborate which launches their class connect sessions. Without it, we can't connect. Continue to allow the option to temporarily allow use. It is only needed long enough to get the application which opens the room running. Once the room opens, I can disable it without closing the room, but without it the classroom does not exist and they don't get to interact with their peers and teacher, nor can they access the recordings for sessions they missed. We need this, but only as optional!!!
It says resolved fixed, so why does it continue to get flagged???
(In reply to Ana from comment #41)
> Please don't permanently block this. My children's Virtual Academy uses it
(In reply to Ana from comment #42)
> It says resolved fixed, so why does it continue to get flagged???

This plugin is blocked because there is a security thread. Blocking is the solution. 
The real work has to be done by Oracle.

May be your Java version is outdated and needs to be updated. That's your job.

See answer Comment #39: 
https://bugzilla.mozilla.org/show_bug.cgi?id=636633#c39

"This Java message has nothing to do with the Java Deployment Toolkit.  
See these Java Help pages:"
http://www.java.com/en/download/help/appsecuritydialogs.xml
http://www.java.com/en/download/help/java_blocked.xml
Thank you so much for blocking this.  Now I can't upload any pictures to my Weight Watchers website.  You give me no alternativeS or choice.

GOOD JOB!  THANKS A LOT
(In reply to mkeawsh_2000 from comment #44)
> Thank you so much for blocking this.  Now I can't upload any pictures to my
> Weight Watchers website.  You give me no alternativeS or choice.
> 
> GOOD JOB!  THANKS A LOT

Please familiarize yourself with our etiquette guidelines before posting any further comments in Bugzilla. Thank you.

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
(In reply to forumkurt from comment #43)

> This plugin is blocked because there is a security thread. Blocking is the solution.

Any PC that's turned on and connnected to the Net are vulnerable by it's nature. So let don't stop at this very limited solution.

Either did You mean "threaT"? If so can You pls be so nice to proof Your claim? May be You've got a some top-secret notification from Oracle?

> The real work has to be done by Oracle.

And Oracle did nothing up to now, do You mean this?

Anyway the key question still very clear:
are this so called "security" (blocklisting) decisions based on the real world or just paranoidal "but it's possible"?
(In reply to vitar from comment #46)

Everyone can reactivate this plugin on demand. So, whats your point? 

You are asking rhetorical questions. Contribute, don't ask.

I don't need this plugin. But I'm heavily relying on updated Java Runtimes. 
I support your effort, but not your tonality.
(In reply to forumkurt from comment #47)
> (In reply to vitar from comment #46)
> 
> Everyone can reactivate this plugin on demand. So, whats your point? 

Why is Firefox blocking this plugin and notifying me if the security problem was fixed? Yes it's good that I can manually tell Firefox via a prompt that I feel happy about using it on this site. But why should I need to white list sites at all? I am already getting a pop-up from Java too so why do I need one from Firefox as well for white listing?

All my add-ons are up to date including Java. Yet the "Java Deployment toolkit" is still blocked even though it is running the latest version. Can this not be re-evaluated and allowed back if it is fixed. Or can we allow people to change it back to "Activated" which would disable the white listing config.

Java Deployment toolkit version 7.0.510.13
Will not reactivate on command.  Have tried many times in the past week - will not reactivate on demand.  Keep getting blocked and the warning.  Java is all up-to-date.
The "click to play" does not work as it is stated.  The option to allow does not work and the option to allow and remember does not work.  Once clicked (allow or allow and remember), Oracle reminds me that the extension has been blocked due to my security settings...but my security settings say the website is allowed. Even after "allowing" a temporary "unblock" I cannot access the desired content due to a block that cannot be "unblocked" by the user.

It appears now that the bug is on your end Mozilla.  Would someone mind looking into this please?

Thanks in Advance.
Thank you Bradboding.
(In reply to bradbolding from comment #50)
> It appears now that the bug is on your end Mozilla.  Would someone mind
> looking into this please?

Please file a new bug report with detailed steps to reproduce.
Thank you very much for the information.

I have seen the video demonstrating your support
and is correct.

Generally they warned me similar questions
around 2009 , can not remember the date
time, where I indicated that the file
host system was modified to download the application
or updated.
The command referenced is very popular
sites for instant messaging , chats or
similar.
But he's been locked scripts
notice of initiation site appears to
enable java plugin support .
This is where the kit is the question
as the site administrator you may
control or access your temporary file
hosted on your device.
As you say , someone with a shared network
You can modify the host file system , not just
modify your system or programs , but to create a
zombie computer , ignoring users
affected the dangerous vulnerability, etc. .

Many webmasters configured their place
flash format and not in java, for reasons
more dynamism and safety in
places besides vulnerabilities
experts who comment here .



Anyway I have my settings
blocked host file voluntarily
and I 've localhost
to avoid unwanted intrusion of other friends.

C : Windows \ System32 \ Drivers \ etc \ hosts

Also as you know you can edit the
host file system with a bat . or batch
introducing a script. ( notepad) .
You can also clean up files
and replace the temporary file
boot host or initial configuration
the host system , friends aid programs
as Combofix and file
format options at bat . with
command scripts .

Of course when I refer to scripts
a website has nothing to do with java .
( I say that messages appear Mozilla
Firefox remembering the difference for help
users ) .

Great information and very well
explained for the help of users .
The "lazy" solution to this bug is most likely the cause of my annoyance with the plug in check over and over and over when starting Firefox. Remove the block, and work on your own bugs please, and at a minimum add and ignore feature to the blocklist system - such as "ignore blocklists created out of laziness".

" Daniel Veditz [:dveditz] 2013-06-25 00:54:59 PDT

Yes, people running the old versions are still at risk. We should just blocklist the Java Deployment Toolkit Plugin entirely (click to play) since it's not used to run Java applets (that's a separate Java Platform plugin) and is generally unnecessary."


 I can assure you, that most people will tire of attempting to fix a FireFox Developer annoyance like this by switching to a different browser when they have to search and search for answers that yield no results.
Is this still an issue with JDK 8? I find it odd that -all- versions of this plugin are blocked by default...
Flags: needinfo?
(In reply to whytedem0n from comment #55)
> Is this still an issue with JDK 8? I find it odd that -all- versions of this
> plugin are blocked by default...

Please take your concerns to the dev-platform mailing list.
Flags: needinfo?
Will you please unblock this?  We don't even have the choice to enable it and without it you are quickly becoming unable for many things and even crash all of the time.  this forces me to use Google Chrome or another browser and degrades the ability of Firefox which I would prefer to use.  There is no heightened security threat by using the Java deployment kit on Firefox any more than there is on any other browser.  You are only going to lose loyal users by keeping this banned and as of this morning you have it where it cannot be enabled in my 28 or 28.1 browser.

Ty, A11
Ty, Your request is one of many for months now.  I just use IE now and uninstalling Firefox.  That is my suggestion to you.
Because of this blockade i can not use the virtual keyboard of an online phone service, as unlocks? This only caused me trouble. >:(
(In reply to Rada from comment #59)
> Because of this blockade i can not use the virtual keyboard of an online
> phone service, as unlocks? This only caused me trouble. >:(

As mentioned in Comment 56, this bug is not the place for discussions - please go to the dev-platform mailing list https://lists.mozilla.org/listinfo/dev-platform
Lukas Blakk: "As mentioned in Comment 56, this bug is not the place for discussions - please go to the dev-platform mailing list https://lists.mozilla.org/listinfo/dev-platform"

Lukas - This bug is clearly where the original issue, which was  FIXED LONG AGO by Oracle, was discussed and where the arguably heavy-handed "solution" was discussed and agreed upon.

The "warning" that is raised is undeniably extremist and casts serious aspersions upon Oracle, and Java in general.  The wording that appears is:
"Java Deployment Toolkit (click-to-play) has been blocked for your protection.

Why was it blocked?
    The Java Deployment Toolkit plugin is known to be insecure and is unnecessary in most cases. Users should keep it disabled unless strictly necessary."

KNOWN TO BE INSECURE!???   It was a single bug in a long-dead release of the toolkit.  THIS INACTION BY FAIRLY AMATEUR (wannabe perhaps) DEVELOPERS SEEMS TO BE POLITICAL IN NATURE.  

I'm a s/w developer of a couple decades - from Sybase SQLSvr, network solutions to weblogic then BEA and on the JRockit jvm team.  I've also been a loyal and enthusiastic user of Firefox since it was Mozilla and was spawned from Netscape eons ago.  I have continued to defend Firefox through various stages and phases - and believe it's achieved amazing things.  But - I do not understand the total pushback and unwillingness for anyone on this team to accept responsibility for this.  IT IS TIME FOR THE WORDS "known to be insecure" which were poorly chosen to begin with to go, along with this block.  

I applaud the efforts that went in to determining this issue and Neal's work with repro environ and offering it to interested parties, etc..  but now this seems more like an unprovoked slap-in-the-face to Oracle (I'm not a big fan -- but Java is still an important technology, imho - and that's the real victim here - Java itself.  Clearly, even though the folks that decided upon the hammer-as-a-screwdriver approach don't think so, there are people who continue to make use of the toolkit - and rather than be put-off to Java, they will simply be put-off to FIREFOX.  If that's ok with everyone, then by all means continue to look the other way.  THIS BUG IS WHERE THE DISCUSSION WAS, AND WHERE THE DECISION TO BLOCK WAS MADE - SO THIS BUG IS WHERE THE REMOVAL OF THE BLOCK SHOULD BE FACILITATED.  Shine it on if you really just don't care (Lukas, Anthony - yeah, you guys).

Stephen Francis
Stephen, Bugzilla is not the right place to have this discussion. Your concerns are quite valid but should be posted to the dev-platform mailing list. If we ever entertain the proposal to remove this block it will not happen in this bug. The discussion will happen on dev-platform and the implementation of the removal will happen in a new bug on Bugzilla.

Respectfully, please take your concerns to dev-platform.

Thank you
Hello,

 I agree with what Stephen is saying above, and he states it much better than what I can in the amount of time I have. Lets try to look at this same issue from a slightly different perspective.

Google learns of a security vulnerability in Firefox 2.0 in June 17th, of 2008 (http://dvlabs.tippingpoint.com/blog/2008/06/18/vulnerability-in-mozilla-firefox-30). And places an "advisory" and a "block" of users who are using Firefox*.*.* and attempting to locate and download Firefox*.*.*. 

Firefox identifies and fixes the bug and releases an update in 2 days and yet in 2014, we are still seeing the "advisory" and still having to use search engines other than Google in order to locate Firefox*.*.*. and its download sites. Then Google states please do not post on the initial article that initiated "defcon 4" against Firefox, please use this site in dev.platform.obscureville.com. PS Firefox is insecure! Be careful!

As an end user, why should myself or others go to a site designed for developers. The simple fact is this, if I have to tell a developer that the practice(s) they are following are not logical in any way... I can only hope that they are soon out of a job. Furthermore, I can only surmise that by "encouraging" people to jump through hoops to rectify an issue that started with this very web page, is just a polite way of telling us to bug off. (pun intended :) )

You do not close a street because of a pothole, you simply patch the pothole and move on. The choices made in regard to this bug were created from nothing but pure laziness. You closed the street the pothole was fixed. Yet you have others sit watch to assure it stay closed?

Status: NOT RESOLVED IMPROPER FIX IMPLEMENTED
Root Causes: laziness/arrogance/egotism

"If we ever entertain the proposal to remove this block..." from Anthony Hughes sums up the attitude here perfectly. Obviously you all have an "agenda" and are simply hiding behind artificial procedures because it makes you feel good. 

However, the main point here is that your initial action and continuing non-action to correct the issue started here are detracting from the Firefox user experience in a negative way on a continuing basis. You are at fault, not Java, not Oracle, you.  A (real) developer would not be "ok" with that - only those who want to play politics and pretend to be proffesional [sic] developers are.

Respectfully, enjoy your short careers!
Just uninstall - I did.  They are too full of themselves to admit they made a mistake.
Please move this discussion to the dev-platform mailing list, as previously requested. Thank you.
Very interesting stuff, ladies and gentlemen. Of particular interest is the instruction provided earlier, to refer to the Bugzilla etiquette page, contrasted with a later (repeated instruction)to move this "discussion". And then if one actually DOES read the etiquette page we find the following: 

"...Please place all information relating to bugs in the bug itself."

Yes, all very interesting. Also, before it is brought up, there is no violation of point #1, No Pointless Comments. This comment has a point. The point is that this nuisance, now well documented right here for over 3 years, has not been resolved satisfactorily. Users questions have not adequately been answered. And yet another user is on the verge of going back to IE, full time, rather than part time. If this isn't enough of a concern to address here more adequately than it has, perhaps it will be addressed via some other means. Perhaps I and others should follow the etiquette page, Section 3. Applicability that reads

"In the case of persistent offending you should ping an administrator on Mozilla IRC in channel #bmo and ask them to look into it."
I think we've been very reasonable, respectful, and patient having offered a solution to moving forward on this. For the last time, if you want to engage in a rational conversation about this then please start a dev-platform thread. If all you want to do is vent your frustration, by all means, continue to comment on this bug.
Having read the description it seems to me that any online app will have this same vulnrability. I am no computer programer, but I am a computer geek, I would say having aspergers gave me a unique bond with computers. 

An online app has to be served from a host, that host has to have an ip, the app has to know that ip, their is one vulnrability. You can decompile the code in any online app and get the ip for the host. Second vulnrability, "The plugin allows Javascript in the browser to trigger an installation by calling an installLatestJRE() method. When a call to installLatestJRE() is made, the plugin makes a request to java.sun.com over HTTP to fetch the installer, which is an EXE." This does not apply just to java, any plugin has a call procedure to trigger a install (this is were I know nothing about programing code lol), what im trying to say is any plugin that has a section of code in it that is designd to ask a host to send it a exicutable file, weather, it is exe, bat, isu or pptm, is a security risk. This is because if the plugin is designed to request a file from a specific host or set of hosts, the ip address's for the host's will be in the code you just got to decompile and than possably decrypt. If the plugin keeps logs of previous hosts its connected to that you just got to decompile the log files. All you have to do to change the host ip is decompile change the ip and compile the code again. than host it, and you can send millions of people a program with out them even realising it. 

One teqniue many hakers use to spread a virus, is to cloak a virus as something that will look normal, a desktop icon for example. a small Pi symbol about the size of the speaker icon on a laptop (do not click it, it is a perticularly dangorus trojan that starts spreading as soon as it is on a computer, it remains dorment till clicked and than brings down major systems like finances, comerce, transport, military, goverment that's how they designd it to work) I only know that someone must have had first hand experience of the effects of this computer virus or they wouldent have based an entire film on it)
So make sure you are aquanted with the GUI's of your applications both local and online, and the codes that run them.

Offten a virus will be desguised as a microdot and replace the dot on top of the i or replace a full stop.
Hackers do this because most people do not suspect this, So it is also a goot idea to pay attention to your fonts as they appear on screan and learn how to touch type.

Third security threat. I need to take a load off, ttfn.
Comment on attachment 8359173 [details]
firefox.exe

well i need help to get this unblocked or get another plugin
Flags: needinfo?(neal)
(In reply to janeen from comment #69)
> Comment on attachment 8359173 [details]
> firefox.exe
> 
> well i need help to get this unblocked or get another plugin

Please don't attach exe files to bug reports. I suggest you ask for help at support.mozilla.org, we cannot provide the help you need via this bug report.
Flags: needinfo?(neal)
I must agree with the others that this blanket blocklisting is sheer laziness.
How hard can it be to check the Java Deployment Toolkit version and block only the vulnerable versions?
Can Mozilla developers not write a simple if-then statement? It wouldn't even require an else part.

Anthony; there is no thread about this at dev-platform and why should there be? I seems like a brush-off to me. This issue originated here and here is where the final resolution should be made. You seem to have been in direct contact with them from the beginning so why can't they get back on this like you are and apply a simple solution instead of killing a fly with a shotgun?
They don't know how to do anything but the "shotgun" approach.  Don't think they have the knowledge.  That is why they get so defensive when we ask for a simple resolution and tell us to go to the correct platform to discuss it.

Haven't used Mozilla for months now.
(In reply to Ian from comment #71)
> I must agree with the others that this blanket blocklisting is sheer
> laziness.
> How hard can it be to check the Java Deployment Toolkit version and block
> only the vulnerable versions?
> Can Mozilla developers not write a simple if-then statement? It wouldn't
> even require an else part.
> 
> Anthony; there is no thread about this at dev-platform and why should there
> be? I seems like a brush-off to me. This issue originated here and here is
> where the final resolution should be made. You seem to have been in direct
> contact with them from the beginning so why can't they get back on this like
> you are and apply a simple solution instead of killing a fly with a shotgun?

Well no one else has bothered to bite the bullet offered up by Hughes so I found
support.mozilla.org
and (struggled) to Register (not very intuitive process I must say, you have to Ask a Question and the Registration/Login is part of that process) as follows:
=======================================================
Question title: Why does Firefox continue to state that the Java Deployment Toolkit is known to be vulnerable.

Description/Detail
The original issue with Java has been fixed yet FF continues to state the same warning which must be confusing at least to some and a road block for others at worst?
So, I'm posting a question, which is really a request that the Devs remove this warning.
There's a thread
https://bugzilla.mozilla.org/show_bug.cgi?id=636633
that 'discusses' this and a person  	Anthony Hughes, QA Mentor (:ashughes) that
has said that this issue should be posted 'somewhere for the devs' but didn't provide a link/path to help us get there to post.
=======================================================

Hughes calls himself a Mentor? 
The etiquette says that we should be nice, understanding, etc since the Mozilla Team is "made up of people just like us". Well Hughes is definitely not like me. I would have gone to the site, posted the issue and then shown the link to the thread in my post here. How simple it could have been, and a way to avoid all the distressed posts here.
Huh, That's exactly what I did. Are you reading this Hughes?
(In reply to APraxis from comment #73)
> (In reply to Ian from comment #71)
> > I must agree with the others that this blanket blocklisting is sheer
> > laziness.
> > How hard can it be to check the Java Deployment Toolkit version and block
> > only the vulnerable versions?
> > Can Mozilla developers not write a simple if-then statement? It wouldn't
> > even require an else part.
> > 
> > Anthony; there is no thread about this at dev-platform and why should there
> > be? I seems like a brush-off to me. This issue originated here and here is
> > where the final resolution should be made. You seem to have been in direct
> > contact with them from the beginning so why can't they get back on this like
> > you are and apply a simple solution instead of killing a fly with a shotgun?
> 
> Well no one else has bothered to bite the bullet offered up by Hughes so I
> found
> support.mozilla.org
> and (struggled) to Register (not very intuitive process I must say, you have
> to Ask a Question and the Registration/Login is part of that process) as
> follows:
> =======================================================
> Question title: Why does Firefox continue to state that the Java Deployment
> Toolkit is known to be vulnerable.
> 
> Description/Detail
> The original issue with Java has been fixed yet FF continues to state the
> same warning which must be confusing at least to some and a road block for
> others at worst?
> So, I'm posting a question, which is really a request that the Devs remove
> this warning.
> There's a thread
> https://bugzilla.mozilla.org/show_bug.cgi?id=636633
> that 'discusses' this and a person  	Anthony Hughes, QA Mentor (:ashughes)
> that
> has said that this issue should be posted 'somewhere for the devs' but
> didn't provide a link/path to help us get there to post.
> =======================================================
> 
> Hughes calls himself a Mentor? 
> The etiquette says that we should be nice, understanding, etc since the
> Mozilla Team is "made up of people just like us". Well Hughes is definitely
> not like me. I would have gone to the site, posted the issue and then shown
> the link to the thread in my post here. How simple it could have been, and a
> way to avoid all the distressed posts here.
Well the response to my Question was useless. It suggested starting FF in Safe Mode to see if the problem still existed. How lazy is that?

Starting FF in Safe Mode provides no way to check Addons > Plugins.

So my question now is: How do we find the dev-platform mailing list so that we can post there?
Quit using Mozilla.  That totally resolved this issue for me months ago.  This company is not worth it.  They don't care.  IE may have issues but can at least get someone to respond and give cognizant suggestions.
(In reply to mkeawsh_2000 from comment #76)
> Quit using Mozilla.  That totally resolved this issue for me months ago. 
> This company is not worth it.  They don't care.  IE may have issues but can
> at least get someone to respond and give cognizant suggestions.

I disagree, your reply reeks of giving up rather than remaining strong. 

True, Hughes the Mentor, while possibly attempting to be helpful, wasn't. But giving up simply lets incompetent people continue to be incompetent. After all, they aren't likely to lose their jobs and even if they did, they aren't paid, so they haven't lost much other than the rights to brag that they're FF devs. (Well, some may brag, others may try to hide that fact.)
It's interesting to note that Hughes' profile states that he's submitted 729 bugs.
An appropriate question would be: "why didn't he simply file the bug himself and avoid all the subsequent posts?"
However he's no longer on the cc list so it's unlikely that he'll provide an answer.
(In reply to APraxis from comment #77)
> (In reply to mkeawsh_2000 from comment #76)
> > Quit using Mozilla.  That totally resolved this issue for me months ago. 
> > This company is not worth it.  They don't care.  IE may have issues but can
> > at least get someone to respond and give cognizant suggestions.
> 
> I disagree, your reply reeks of giving up rather than remaining strong. 
> 
> True, Hughes the Mentor, while possibly attempting to be helpful, wasn't.
> But giving up simply lets incompetent people continue to be incompetent.
> After all, they aren't likely to lose their jobs and even if they did, they
> aren't paid, so they haven't lost much other than the rights to brag that
> they're FF devs. (Well, some may brag, others may try to hide that fact.)

Was on here verbalizing my concerns at the beginning of the year and got responses to either go to the correct place or go to the guidelines on etiquette.  Needed to access java and can not do it with Mozilla and could not wait until they got off their "mightier than thou" thrones to resolve the issue. They are too concerned about being right.  Had to resort to another browser.
(In reply to APraxis from comment #78)
> It's interesting to note that Hughes' profile states that he's submitted 729
> bugs.
> An appropriate question would be: "why didn't he simply file the bug himself
> and avoid all the subsequent posts?"
> However he's no longer on the cc list so it's unlikely that he'll provide an
> answer.

He is still on the cc list - anthony.s.hughes.
I'm restricting further comments on this bug. Bugzilla isn't intended as a debate forum. As Anthony and Lukas suggested, the place to have this discussion is dev-platform: https://lists.mozilla.org/listinfo/dev-platform

[Comments are restricted to users with the editbugs privilege -- with privilege comes responsibility, so please consider carefully before commenting if you are able.]
Restrict Comments: true
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.