Update: Bugs with Internet Explorer and Java, described here on Page 3, were confirmed by CERT and added to their Vulnerability Note VU#625617 on January 22, 2013.
The recently released Java 7 Update 11 changed security rules that had just been introduced with Update 10. The ink was barely dry, so to speak. Here I hope to explain the rules for running Java programs embedded in web pages. This is needed, because Oracle has done a poor job throwing information over the wall from their in-house techies to their non-techie users.
Java 7 Update 10, released just last month, introduced security levels on the Security tab of the Java Control Panel. As you can see below, the levels are Low, Medium, High and Very High.
Update 10 defaulted to the "Medium" level which, by and large, was transparent to end users. However, Update 11 changed the default to "High" which causes Java to issue warnings that few people have any chance of understanding.
To put this in perspective, these security rules/levels only apply to Java programs embedded in web pages. The use of Java by installed applications remains totally unregulated. Also, the security rules only apply to Java version 7, they were not implemented in Java version 6.
BACKGROUND CONCEPTS
To understand the new rules, you first need to first be up to speed on two concepts: digital signing and the Java security baseline.
The security baseline refers to a particular version/update of the Java Runtime Environment (JRE). The JRE is the part of Java that gets installed on Macs, Windows and Linux machines and actually executes (or runs) Java programs.
Oracle makes a distinction between bugs in the Java Runtime Environment that are security related and those that are not. Adding one plus one and getting three, for example, is not a security vulnerability.
Computerworld Blogs Newsletter
Subscribe now to the Blogs Newsletter for a daily summary of our most recent and relevant blog posts.
When Oracle releases an update to Java that fixes security bugs, the new release is considered the security baseline edition. If they release an update to Java that does not fix any security bugs, then that new release does not change the security baseline.
Simply put, the security baseline edition of Java is the last one that contains security related bug fixes. You can see the security baseline in the release notes from Oracle (see Java 7 Update 11 Release Notes).
Currently, Java version 6 illustrates the concept. Update 38 contained bug fixes, but none were security related. Thus Java 6 Update 37 (which did contain security related fixes) is the security baseline edition for Java 6. Windows users that want to get two, when they add one and one, can install Java 6 Update 38. Mac users, by the way, can not. Apple has not released Update 38 for Java 6.
Since Java 7 Update 11, the latest release, contained security related fixes (oh boy, did it), it is the security baseline edition for Java 7.
The other concept that needs to be understood is that of digital signing.
Like other executable files, Java programs embedded in web pages can, optionally, contain a digital signature. The signature tells us who created the program. Thus, you and I can determine whether to trust a signed Java program based on how much we trust the company that created it.
Java programs without a digital signature could have been created by anyone. On my javatester.org site, I publish the source code for the small applet that runs there. But nothing on the site proves that I created the applet. The site could be hacked tomorrow to run a malicious applet.* The proofing system is far from perfect, but, it's all we've got.
Running unsigned Java programs (or any unsigned executable program) is like drinking milk from a carton that doesn't have an expiration date (no sniffing allowed either). You are blindly trusting that the milk has not spoiled.
NEW WARNING
The new default Java security level of "High" means that many Java users will start to see the message below (the screen shots are from time.gov on a Windows machine).
First, I have to gripe.
Note that Oracle does not include the word "Java" anywhere in this warning. Most computer users will have no clue that the message is Java related. This shameful state of affairs is why so many non-techies just click through any and all warnings. Who can blame them?
The confusion continues if the end user clicks Cancel. As shown below, this results in an error and the option to click for details.
The "details" alluded to are non-existent. As you see below, it restates the obvious, that the application failed to run.
Again, there is nothing about Java in this message either.
As if this were a cruel joke, a confused user can, yet again, click for details. But, this second plea for useful information is another disappointment. As you see below, all that's displayed is the Java console. What we have here is a failure to communicate. At least the word "Java" finally appears.
*If you look in your Java cache or browser cache, the total size of the legit applet is 929 bytes.
EXPLAINING JAVA SECURITY
The first message window ("Do you want to run this application") resulted from the new default security level of "High". According to Oracle, at this level "You will be prompted before any unsigned Java app runs in the browser". They fail to mention that the prompt says nothing at all about an unsigned Java app.
Note that the explanations of the security levels in the Java Control Panel itself are short, incomplete and useless. I had to hunt with my favorite search engine to find what I could from Oracle.
With Update 10, the default security level was "Medium" which meant that unsigned Java programs ran without warning, as long as the installed copy of Java was at the security baseline. Sort of. From what I have been able to gather from Oracle's documentation, it's not that simple.
As part of the normal course of events, the Java runtime tries to phone home looking for updates. If it can't connect to the home office for an extended period of time, then it is supposed to consider itself risky and it will start to warn users about running unsigned programs, even at the "Medium" security level. I have not tested this, and not being sure how long the timeframe is, I can't.
The upgrade from "Medium" to "High" security means that end users now get warned for any and all unsigned Java programs embedded in web pages. Many such Java programs are unsigned. Probably, most of them are unsigned.
The one at time.gov is not signed. Neither, as I mentioned, is mine at JavaTester.org. Oracle hasn't bothered to digitally sign their own program that tests whether Java is working on a computer. Likewise, Oracle's Verify Java Version page also runs an unsigned Java program. Go figure.
At the "Very High" setting no unsigned Java programs can run. Signed ones, though, are good to go. Below is a sample of the error window that pops up on Windows 7 when you try to run an unsigned Java program on the Very High setting.
The only signed Java program that I regularly use is the Secunia Online Software Inspector. Actually, it's the only signed Java program I've run across in any web page.
Sad to say, the blocking of unsigned programs doesn't always work. On a Windows 7 machine, Internet Explorer 9 happily ran unsigned Java programs on the Very High setting. Firefox and Chrome correctly observed the rules. More on this below.
At the Super Duper Ultra High security level, no Java programs embedded in web pages can run. It does not matter, at this level, whether the Java program is signed or not. It also does not matter whether the installed version of Java is at the security baseline or not. And, finally, it does not matter if you are using Internet Explorer. IE 8 and 9 obey this rule.
That's the good news. The bad news is that your web browser is probably going to lie to you. Rather than report that Java is configured for off-line use only, my experience (on Windows) has been that all browsers wrongly report that Java is not installed.
Also on the down side is that the term "Super Duper Ultra High" is mine. Oracle refers to this security level as "Enable Java content in the browser". And, rather than being the highest level on the security settings slider, it is implemented as a checkbox (see back on page 1).
The only thing that needs to be said about the "Low" setting is that friends don't let friends surf the web in such a state.
The rest of the rules for running digitally signed Java programs can be found here: Setting the Security Level of the Java Client. Despite a reasonable understanding of the concepts involved, I couldn't make much sense of it. Anyone reading this that can find a better explanation is welcomed to leave a comment below.
INTERNET EXPLORER IS A MESS
As noted above, my initial testing on Windows 7 revealed a bug in Internet Explorer 9 - it ran unsigned Java programs on the Very High security level. Since that particular machine had been used for a lot of stuff, I tried another Windows 7 machine, one with a fresh copy of both IE 9 and Java.
At first, Internet Explorer behaved itself, blocking unsigned Java programs when the security level was "Very High" and issuing the same message as other browsers. Then I tried Super Duper Ultra High security to block all Java programs in all browsers. This also worked, but Internet Explorer initially issued a warning that it had prevented the installation of an ActiveX program. Thereafter, it blocked unsigned Java programs without issuing any warning message.
Internet Explorer was pretending as if Java never existed. Pity someone trying to figure out why a Java program seems to have disappeared into thin air.
Next, I re-enabled the use of Java in browsers and things got worse.
At this point, IE issued a message at the bottom of the screen that Java was ready for use along with buttons to enable it or not. I enabled it. Now, just like on the first Windows 7 machine, Internet Explorer is again running unsigned Java programs, without warning, even though the security level is Very High.
Moving over to Windows XP, I found that Internet Explorer 8 has it's own Java related bug. The same condition, blocking all Java content in web browsers and then re-enabling it, proved fatal.
The first time IE8 tried to run a Java program, after this had been re-enabled, it crashed with the DEP (Data Execution Prevention) error shown below
Thereafter, IE8 would not run any Java programs. Later failures were a bit different (see below), rather than crash, IE brags about how it protected your computer from a malicious add-on.
This is not new. In their recent Vulnerability Note VU#625617, CERT wrote "... we have encountered situations where Java will crash if it has been disabled in the web browser as described above and then subsequently re-enabled". They suggest reinstalling Java.
I did not test Internet Explorer version 10.
WHATS NEXT
The checkbox at the bottom of the "Do you want to run this application" security warning, "Do not show this again for this app" needs some more research and testing.
For example, does granting no-nag status (my term) to a particular Java program apply to all users of the computer or only to the currently logged on user? Also, I have been unable to find the list of Java programs that have been granted no-nag status. Any system that can't be audited is ripe for corruption. Who would know, if a bad guy somehow added their Java programs to the list?
I'm a Chrome user, and with Java 7 Update 11, I find myself being doubly nagged. To its great credit, the Chrome browser has been warning before running Java for a very long time. And, like the new warnings from Oracle, Chrome also supports of lists of Java programs you no longer want to be nagged about. However, the Chrome list of no-nag Java programs seems to be totally divorced from Oracle's list.
Is it just me who thinks this is way too much hassle for far too little benefit?