I installed Java version 45 on a test machine. High security setting says that one can can't run unsigned or self-signed apps on older versions of Java, and in fact it fails to run a self-signed applet.
How is this version able to detect that it is an older version? It certainly wasnt an older version when it was first deployed.
Java configuration, mainly the security baseline, gets updated as soon as you receive the new version notification, even if you choose "update later" . At that point you are executing java 7u45 but using an updated launcher, so it knows you have an older version running, and it applies the updated security checks.
I would assume that somewhere in jnlp internals it makes a call to oracle's servers and checks what version is the latest and whether it your currently running version is old.
You can inspect the calls with a packet inspector and even try to spoof it to see whether you can circumvent that rather crude security measure.
Related
Greetings .
I've encountered a Java Error ,which is actually giving me a nightmare .
It says :
" Application Blocked by Security Settings "
" Your security settings have blocked an application from running with an out-of-date or expired version of Java "
Java Version : 1.7_25 ( Recommended for my work and not an old one i believe)
Workaround i have performed (which did not work) :
Lowered Security Level to Medium.
Cleared Browser Cache and Cookies.
Checked a few settings in the Advanced Tab of the Java Control Panel like :
General : Allow user to grant permissions to signed content.
Java Cache was also cleared.
Even after performing the above workarounds, one after other, the issue doesn't go and there is no exceptions site list in the security tab either(just for information).
Majority of the issues related to the error would go after the security level is lowered to medium. But mine doesn't.
Hope some one could help me out.
Shall be ever grateful.
Thank you !
AK
"[Java 1.7.0_25 is] recommended for my work and not an old one i believe".
Unfortunately, your belief is incorrect. As of now (when you asked the Question), Java 1.7.0_u25 is over a year old, and there have been 4 security-relevant releases to Java 1.7 since that release.
In fact, you probably don't have any option apart from upgrading ... if you want to use that application via your web browser. The version checks cannot be overridden (AFAIK) for Java applications launched via your web browser and/or using Java Web Start. This is a good thing too.
So how does this jive with your "work recommendation"?
You need to talk to your system admins, or security people, or whoever made that recommendation. Under normal circumstances, it is bad to use an out-of-date version of Java, especially if you enable it in your web browser. It leaves you open to all sorts of security exploits.
It may turn out that there is a sound reason for this "recommendation"; for example a compatibility issue for some other Java-based apps that they need to support. If that is the case, you have a hard choice to make:
You could upgrade to the latest Java 1.7 release and risk not being able to use applications that (really) require an older release of Java.
You could not upgrade, and give up on the idea of using the app that is giving you problems.
You install a second web browser, and configure on to use the latest Java release, and the other to use the older "recommended" release. This could be messy, but (at least) Java is designed to allow you to have multiple JRE or JDK installs on your system simultaneously.
... but my application(on which i am working, unfortunately supports up to this version (i.e. 7_25).
Developing an application that only runs on old versions of Java doesn't seem like a good business strategy.
But assuming there is a good reason, you should be able to install BOTH 1.7.0_25 AND a later version on your system ... and use one for your development work and the other for running web-based applications.
Or if that isn't appealing, then use different virtual machines, or different physical machines for doing the different types of work that you need to do.
"Your security settings have blocked an application from running with an out-of-date or expired version of Java"
Java Version : 1.7_25 ( Recommended for my work and not an old one i believe)
From Java SE Downloads:
Java SE 7u67
This release addresses a regression introduced in the most recent security update. Oracle strongly recommends that all Java SE 7 users upgrade to this release.
You are not on the latest release for version 1.7.
There have been 7 releases since 1.7.25.
Actual problem can be not an outdated Java but applet jar sign/manifest/jnlp.
Workaround:
1.Install latest JRE from Oracle site
2.Uncheck "Enable Java content in browser" in old java/jre (javacpl.exe)
3.Make sure that applet correctly works with latest JRE
4.Uncheck "Enable Java content in browser" in latest JRE and check it in your old JRE
I had same issue, I reduced security level from high to medium and allowed to run the application at risk, it worked for me.
I recommend adding the site URL to the Security Exception Site list without lowering your overall security level.
Is it best practice to develop and deploy on the EXACT same JRE/JDK versions (assuming you can control both ends)? Say you are running JDK 7_45 in production but have 7_51 you your development box. Is that potentially problematic - in your experience? I'm guessing the best practice would be to have them match but just wondering how problematic it could be assuming you are at least using the same major release. I suppose this also goes towards backward compatibility of JVM minor release versions. In the typical user space, I could be running Java apps built over time using many different Java development version JVMs yet all 'should' be expected to run on any JVM version. Would have to 'expect' that since I cannot obviously control the user's installations. My question is more related to the fact that I AM able to control both ends (dev and prod) so would it be wise to use the same JVM/JDK versions? Seems like the obvious answer is YES - use the same versions - if you can.
Generally, developers tend to have the latest version of the JRE/JDK installed on their development environments (Windows/Linux/OSX). This is fine, as long as you ensure that the program will run on older versions as well. So, you can develop on one version and use different version on production, as long as you extensively bug test with the older version to allow for backwards compatibility, or specifically state you are requiring a newer version of Java than is available on the user's system.
After some JDK 7 updates my applet won't work (security exceptions). How I can specify JRE version range to use by client in JNLP file? I want cause him to use only JRE 6, not 7.
What you are trying to do is a Really Bad Idea.
Java 6 has been EOL'ed and that means no more free security updates. So what you are doing is encouraging people to downgrade the version of Java used by their web browsers to an out of date version of Java that is likely to have unpatched security bugs that could soon be being actively exploited to do all sorts of nasty things to the user.
The correct approach is to fix your applet so that it works with the latest JDK update (as well as older ones).
The only way out is ,detect the version of java using in browser and giving him a proper message that ,use java 6 jre.
You might heard about deployJava.js
and check the version like
if(deployJava.versionCheck("1.7")){
//message him
}
I have a project that uses the ScriptEngine to process some javascript, and worked well on my machine, but when i send the projects's jar to the server, i had discovered that the server's JVM doesn't have Rhino built-in, returning null when the code calls a
new ScriptEngineManager().getEngineByName("javascript");
I went to the rhino's download page, get the most recent version, and extracted the js.jar from it, added the jar on the project, but still have the same problem.
The JavaScript Engine is only included in the Sun/Oracle JDK. If you use some other Java implementation like IBM J9 or Oracle JRockit (quite likely on a server), or if you don't use the Sun/Oracle JDK but the Sun/Oracle JRE (even more likely on a server), then you don't get the JavaScript engine.
You need to use Sun's full JDK.
Note also that the JavaScript engine shipped with JDK6 is not Rhino, it's a stripped-down lobotomized version of a several year old obsolote release of Rhino. In particular, it is missing the compiler, which means that performance will probably suck.
Also note that the API is not necessarily compatible between Rhino and the JDK6 JavaScript engine, even if you manage to find that obsolete release of Rhino that it is based on. So, if you want to use Rhino in deployment, you'd better use it in development, too.
And last but not least: just because you make some entry in your Eclipse project file, doesn't mean that your server's classpath is going to magically change. You need to make sure that all your classpaths are properly set up. I don't have any eperience with FreeBSD, but I'm pretty sure that the package management system (FreeBSD ports in this case) is going to at least partially take care of that after a port install rhino.
Are there any known security issues with compiling against an older JDK? For instance lets say Oracle decides to change something in one of their implementations that was to close a security vulnerability. If we compile against the older JDK would we still be vulnerable?
EDIT
We are running against JDK 6 and we compile against Java 5, which is the crux of the issue I was attempting to get at for any one else whom sees this question. For the sake of completeness lets say that in the ant build we target 1.5
EDIT 2
Additionally there is the issue of calls in the application that potentially have private APIs/implementations that are not directly accessed.
Aside from some very hypothetical niche situation that hasn't ever happened yet, the only thing that matters is the version with which the application is executed.
I don't think there are any known security issues that have been "fixed" with #deprecated, because that wouldn't really be appropriate.
There are two issues at play here:
1) You can have your Java compiler produce binaries that are binary compatible with older versions. That affects the language features available to you.
2) You can compile against the Java system libraries of an older version, and that will affect what methods/classes are available, as they are always adding new ones.
But neither of these affects the security of your application. What matters is the runtime version with which the application is executed.
Observe that security problems are fixed between updates, not the major versions, which introduce changes in the language itself. For example, Java 6 is currently at update 21. Java 6 update 19 fixed stuff that was vulnerable in Java 6 update 18.
When Java 6 update 19 was released, updates were released for Java 1.5 and Java 1.4, to fix the same issues in Java 1.5 (update 24) and Java 1.4 (update 26). See the security baseline table here: http://www.oracle.com/technetwork/java/javase/6u19-141078.html
If you compile against JDK 1.5:
Users that are using JRE 1.5 will be vulnerable
Users that are using JRE 1.6 will not be vulnerable
The application will run using the libraries of the users's runtime. Since the vulnerabilities are fixed in Oracle's library, which is now being called by your application, the security vulnerability will be alleviated.
However, since you compile against 1.5, your users will be able to use 1.5. Do anything you can to avoid the vulnerability; if you can't avoid it, detect the JRE version at startup and issue an alert if apporpriate.
If Oracle changes an API (not an implementation) to promote security, they will probably add an #Deprecated annotation but preserve backward compatibility for some time. The annotation will trigger a warning in a newer compiler, but not in yours, and not in the compiled program. (Unless Oracle decides to throw an exception or log a message from the deprecated method.)
I would say that those unfixed vulnerabilities are still there, and you and your app are still at risk.
It'd be the same issue as running with an old, unpatched OS or browser.
It's a good incentive to migrate up to newer JVMs.