Michael Horowitz

Understanding the new security in Java 7 Update 11

January 22, 2013 1:02 AM EST
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. 
 
 Java Control Panel
 
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. 
 
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). 
 
 
Java asking permission for unsigned applet
 
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. 
 
Error message after a Java applet is canceled
 
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. 
 
 

Continue Reading