recently I was researching for common vulnerabilities for a particular version of JRE (1.8.0_151) we still have in use and stumbled over cvedetails.com. The result was pretty confusing, since there seems to be no known CVE for this particular version at all. At least, the page does not list this version. However, the page lists results for all kind of newer JRE versions. This could lead to the (probably false) assumption that version 8.0_151 is more secure as the following newer JRE releases and that there wouldn't be the need to update.
List of all CVEs for JRE on cvedetails.com
Does someone know why the particular version isn't listed or if it perhaps counts together with version 152?
Additionally, what would be your recommended update strategy approaches for JRE respective security. Is there any best practices? I am aware that it is a matter of time and money to invest in regards of testing compatibility with the application to use with, but apart from this, it would be great to be aware of the best reasons to stay up to date with JRE.
Many thanks!
You should assume that the vulnerability exists not just in the specified update, but also in all prior updates of the given JRE version. So if the alert calls out 1.8.0_151, you should assume that the issue exists in 1.8.0_anything-equal-to-or-less-than-151.
This isn't just because it's better to err on the side of caution. It's because that's almost always the actual reality of the situation.
There are a couple of reasons why that CVEDetails summary page is incomplete in the sense of not listing every affected update. The first is that Oracle changed the format of its CVE notices back in 2014. The earlier format was something like this:
Unspecified vulnerability in Oracle Java SE 7u40 and earlier, Java SE 6u60 and earlier, and Java SE Embedded 7u40 and earlier ...
which makes it clear that the vulnerability does not exist only in 1.7.0_40, 1.6.0_60 and Embedded 1.7.0_40. The fact the the vulnerability exists in earlier updates is true for practically every vulnerability, not just in Java but in any software. The only time that's not the case is when a vulnerability was introduced in an update, and thankfully that's pretty rare.
Oracle's newer format is something like this:
Unspecified vulnerability in Oracle Java SE 7u45 and Java SE Embedded 7u45, and OpenJDK 7 ...
which no longer makes any statement about the existence of the issue in earlier updates. Oracle would probably say that they do this because the earlier updates are no longer supported and therefore there's no point in even investigating whether they're vulnerable or not.
In fact Oracle's current format makes that position explicit:
Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Networking). Supported versions that are affected are Java SE: 7u241 and 8u231; Java SE Embedded: 8u231.
Only the currently-supported versions are specified as being affected. But the odds are overwhelming that the issue exists in earlier updates too.
The second issue is that even when the original alert format specified "update NNN and earlier", that "and earlier" part is not reflected in the CVEDetails summaries. For example, the CVEDetails summary for JRE 1.7.0 shows no vulnerabilities for 1.7.0_39, 1.7.0_38, 1.7.0_37, ... even though those were all affected by the "7u40 and earlier" issue in the example of the original alert format I showed above.
Additionally, what would be your recommended update strategy
approaches for JRE respective security. Is there any best practices?
Opinions vary, and opinions are off-topic for StackOverflow. But IMO, whenever a new update comes out (even if it has no security fixes) you should revalidate your app against the new JRE, so you know in advance whether there's going to be trouble when your customers apply that JRE update. If there are incompatibilities then you should resolve those ASAP.
If the vulnerability is severe and is exploitable in your app then you should let your customers know that they should apply the JRE update, perhaps after they've first installed a new update of your app if you found incompatibilities when you revalidated. If the vulnerability is mild and/or not exploitable in your app then you should let your customers know that, let them know if the JRE update requires an app update, and let them decide whether to move to the updated JRE.
Related
I am a hobbyist java programmer using NetBeans IDE. A problem I face with programming in Java is choosing the correct target JRE version. I understand that most of my friends have at least java 6, but few have a totally up-to-date version with which I compile. I know how to compile for a particular target run-time environment on NetBeans; the problem is that by using an earlier target release of Java, the compiler expects code written in that version.
For a specific example, I occasionally use a Java 8 lambda instead of a new Runnable(){}, however the compiler (or at least NetBeans) doesn't accept this 'modern' code. Another example is the use of the diamond operator, or the use of multiple-exception catch statement, neither of which are supported by Java 6. The language evolves and the compiler evolves, but older versions of Java cannot handle the change. To distribute my code, I am forced to use what some might consider outdated code.
My question is: Is it considered good practice or common practice to write Java for an outdated target version to provide compatibility? Is there some form of 'translator' or cross-compiler for Java code?
My question is: Is it considered good practice or common practice to write Java for an outdated target version to provide compatibility?
It is common practice.
Whether it is "good practice" or not, is highly context dependent. There is a pragmatic trade-off between supporting older applications whose developers don't want (or can't) upgrade, and holding back the development of your application by not making use of new (and presumably beneficial) features.
There is no universal "best" answer.
Is there some form of 'translator' or cross-compiler for Java code?
Effectively, no. For old versions of Java there were "retro-weavers" which allowed you to run "newer" Java on "older" platforms. However, this approach seems to have died out by Java 6.
To answer your first question, it really depends on the standards set by the company/office that you are working for.
From my experience, most of time big companies tries to stay with matured and well established development platforms, they might not give the cutting edge features of the new language, but the companies want the base platforms to be stable and secure first. And if the codebase is large and the project has been in development for a long time, they normally don't bother jumping into the new platform, since that means they might have to invest more resources to rewriting/refactoring a lot of code, which is not always economically lucrative.
I love using those features that you mentioned in my personal projects, but in my office works we are still using JDK6.
As for the second question, I think there are no workable things at this moment that can do the "translation" that you mentioned.
From my experience this isn't a big problem in the industry. Java is used mostly on the server, not so much on the desktop. And to setup a server with the required Java version is not a big deal. For desktop applications I also seen the approach to ship the JRE with the application. It is a little bit ugly to ship a small application (let's say 5 MB) with a 60 MB JRE, but in the "enterprise environment" it doesn't matter and is a practical way to provide the correct JRE. However, I don't like this approach since it leaves open questions, like how to ship security updates to the JRE.
And by the way: Is Java 6 still supported? To use an old JRE is pretty big security issue.
Updated
Take http://bugs.sun.com/view_bug.do?bug_id=6857057. We witnessed this in JRE 6u17. How do I know which version of the JRE contains the fix? The general consensus on the Internet seems to be 6u18 - but how can I tell this from the bug database? It says fixed in 6u16-rev, but I don't know what '-rev' means. Also it says it still affects version 6u18 - so is there some time dilation going on?
Note
Originally I assumed I'd need to build against a newer version of the JDK, so asked how I'd know which version of the JDK contained the fix. I've updated the question based on mindas explaining its actually the JRE which contains the fix.
You need to understand the difference between static and dynamic linking. In Java world, all JVMs are obliged to load classes as they are referenced. In other words, your code which was compiled against older JDK version does not have the information about how older JDK implemented a particular method.
Unless the method signature has changed (from your bugs.sun.com link I assume it hasn't), you should not need to rebuild your classes. Even if it had, you would be getting a different error (something like NoSuchMethodException).
Java 7 has been around for a while now. Now if an application is to be migrated to Java 7 without any changes (code/configuration), are there any inherent advantages or drawbacks? I was curious to know what the problems are faced during such migration.
EDIT:
By Migration I mean the code will remain the same but the runtime will change to Java 7 As I mentioned no code/configuration changes, so thing which I think should impact the application is new compiler/VM level default optimizations. So I was looking for anything which would impact the overall application behavior.
The obvious disadvantage at the moment that I'm finding with my app (which was written in Java 7 to start with) is that most people don't have 7, and it takes a bit of effort to get it. The default Java download page at the time of writing still points to Java 6, not 7, and most of the current Linux distributions just seem to have 6 installed by default as well. Ubuntu 11.10 is the first to even have Java in its repository.
Also on the Ubuntu side of things, one thing I've noted is that even if Java 7 is installed, I haven't found a clean way to check if it's the default yet (and again, chances are it's not.) I'm just using a shell script that parses the output from update-alternatives --query java and launches it appropriately.
It was a conscious decision on my part to go with 7 because there were a number of new features in it that I could take advantage of, and by the time said app actually hits the point where I'd consider it out of alpha / beta I hope Java 7 will have gained more of a foothold then anyway!
The advantages pretty much all centre around using the added features - I've found the try with resources construct has made a lot of my code using IO stuff easier to read (no more nested try / finally's inside try / catches) and I'm using some of the extra APIs like the filewatcher API too. I also rather like the fact JComboBox and the underlying models are now generic which saves a fair bit of casting in Swing apps.
In short though, if you're not actually going to take advantage of any of the Java 7 features and you're just upgrading for the heck of it, there's little motivation to do so until Java 7 at least becomes a bit more established. It's made my code somewhat cleaner and been helpful with some of the additional libraries, but it's also caused a fair few headaches as well.
I would also consider the probability/requirement change of running your new code(java 7) in java 6 or less since some features will not compile like the following:
Strings in switch statements
try-with-resources statements
improved type inference for generic instance creation ("diamond operator")
improved exception handling (multi-catch)
Make sure the version of java used on your considered projects is not likely to be enforced before switching.
The question is really "when", not "if". If you have a pressing need for some of the new Java 7 features (doubtful) then it's obvious.
Otherwise I'd personally wait about year or so to weed out any other possible showstoppers & headaches, before seriously considering a migration production and UAT environments.
Still, you should already have an environment with Java 7 running just to get an idea of what you'll be in for. Java 6 will be retired at some point and you should be well prepared to make the transition.
I think mostly you will be fine with the migration, although you should check with link provided by Oracle about the incompatibilities between Java 1.6 and Java 7
http://www.oracle.com/technetwork/java/javase/compatibility-417013.html
There are few source level incompatibilities like "Improved Exception Handling" in Java 7 which could cause some problems
It is good question and my answer is totally based on experience and new features provided by java 7.
All new features ease the work for developer rather than creating cross compatibility issues.
Only drawback i see in cross compatibilities among different thirds party jars.
You can experience some performance issue between two java versions. And it will depend on area of java code, for details please have a look http://inebium.com/post/java-7-new-release-performance-code
I'm currently running my web application on Java1.5 codebase, running it on Tomcat 5.5 and MySql 5. Looking through the list of additions that were added into Java1.6, I have to ask the question, "Is there any compelling reason to move from 1.5 to 1.6?". There seems like an incredible lack of necessary improvements and additions. A lot of changes in Swing (not that interesting). Keep in mind the current web application is stable (-ish) and moving up a version always entails some risk.
Am I missing anything important by not moving up? Is there a good reason to move up?
Faster execution time.
Better dynamic debugging.
Better native look and feel in Swing (not important to web apps).
Supported on Windows Vista (could become important, depending on your platform).
JavaScript integrated into the platform (could be a big deal if you update your webapp).
Better scripting language support (could deploy RoR in theory, if needed).
Lightweight web services platform integrated (might be useful).
Better already integrated JDBC4 support.
In other words, it depends, but generally there's enough to make a compelling argument. There's also enough that you might not benefit from to make a compelling counter argument.
Eventually you will have to change. When you do, if you've made the counter argument to stay the same for too long, you wind up having to fix multiple accumulated historical issues all at once. That can overwhelm a team, so sometimes it is best to stay "just a bit behind" current, but never very out-of-date.
I'm assuming you've looked over the features page, and if you haven't, you should.
Java 5 went "end of service life" in 2009.
The newer VM is faster.
Sun (now Oracle) Java 5 has reached end-of-service-life status on October 30, 2009. That means that Oracle will not do bug- and security-fixes anymore on it, unless you pay for a "Java SE for Business" contract (see the web page for details).
Besides that, Java 6 contains a lot of performance improvements (which might or might not matter for your particular application).
It's usually easier to keep an application up to date if you stay on the most recent version.
(Not bleeding edge, but current).
The transition between 1.5 and 1.7 may require more work than if you make the shift to 1.6 first.
jvisualvm in the JDK is reason enough to upgrade. Allows you to investigate and profile an already running process without any preparation.
In IE, I can use the classid "clsid:CAFEEFAC-0015-0000-0011-ABCDEFFEDCBA" to tell it to use java version 1.5.0_11. Is there an equivalent for Firefox and other browsers?
I can use the classid "clsid:CAFEEFAC-0015-0000-0011-ABCDEFFEDCBA" to tell it to use java version 1.5.0_11
Not any more, you can't, for good (security) reasons. See http://java.sun.com/javase/6/webnotes/deploy/deployment-policy.html
There is an IE-only clsid mechanism for asking for "5.0_(something)" in general - http://java.sun.com/javase/6/webnotes/family-clsid.html . This was introduced in 5.0u7 so if you have any one JRE from u7 onwards installed you get this behaviour, otherwise you get the old and incompatible behaviour.
Sun did not deign to provide a similar mechanism for other browsers until 6.0u10, when they added a bunch more mechanisms for choosing versions and deprecated all the old ones including the 5.0u7 family chooser. See https://jdk6.dev.java.net/plugin2/version-selection/ for all the gory details.
So what behaviour you get depends not only on the browser and whether the version of the JVM you want is installed, but what other versions are installed as well. The new behaviour is at least consistent, but it is completely different to all that went before and not entirely compatible. By the time your apps' deployment HTML has been updated to cope with it, they'll probably work with 1.6 anyway.
So in summary, as usual with applets, the whole thing's a bloody mess. Yay.