The last time Oracle released a new version of Java was less than a week ago (March 4th). Yet, there are already a dozen known, un-patched bugs in this latest release (Java 7 update 17). Didn't take long. It never does.
Our story starts way back on February 19th when Oracle released the prior update to Java (v7 is update 15). This fixed about a half dozen vulnerabilities and should have finally closed the door on Java bugs since it quickly followed a massive update on February 1st that fixed 50 flaws. But, rather than ending the flood of Java bugs, it just started a new one.
BUGS 1 - 7
Six days after the February 19th release of Java 7 Update 15, two new Java flaws were identified by Adam Gowdiak of Security Explorations. If finding bugs in Java were an Olympic event, Mr. Gowdiak would be the gold medal winner. He referred to these bugs as issues 54 and 55.
Oracle agreed that issue 55 was a new problem, but disagreed about issue 54. This led Gowdiak to do further detailed investigations. After about five days, Gowdiak still felt that issue 54 was indeed a bug, in that the behavior of the system did not match the documentation. More importantly though, his investigation turned up five new problems.
It took Gowdiak roughly 13 days to find 7 new flaws in Java 7 Update 15. None have yet been fixed.
BUG 7.5
Nine days after Java 7 Update 15 was released (Feb 28, 2013), FireEye and CyberESI reported that a Java flaw was being actively exploited by bad guys to install malware on Windows computers. Macs and Linux machines were not targeted. The attack got a fair amount of publicity which eventually revealed that the bug was first reported to Oracle early in February.
Oracle responded by updating Java on March 4th. Java 7 Update 17 fixed the flaw that FireEye reported, along with another similar one.
That still leaves the count of known, un-patched flaws at seven, as none of Gowdiak's flaws were fixed.
BUG 8
The next issue has to do with defaults.
To put this in context, the security issues with Java only apply to Java programs, typically referred to as "applets", running inside a web page. Anyone who installs Java, and then disables its use by all web browsers, is perfectly safe (for more on being safe with Java see my blog How to be as safe as possible with Java ).
Java applets come in two flavors: signed and unsigned.
I think its fair to say that the vast majority of Java applets are unsigned which, by definition, makes them untrusted. Unsigned applets run in a Java sandbox that walls them off from most of the host computer. When Java security issues make the news, they are inevitably flaws that let unsigned applets break out of this sandbox.
Digitally signing a Java applet gives end users (you and me) reasonable assurance of the person/company/organization that created it. The assurance has more holes than Swiss cheese, but it's all we've got. The applet may be buggy, of course, but if we trust the people that created it, then we trust that it is not malicious.
Signed applets don't run in the sandbox at all. They are considered trusted and can access anything on the host computer, including all the files. The recently introduced security levels for Java 7 only apply to unsigned applets.
One of the few signed Java applets that I've run across is Secunia's Online Software Inspector. Since it scans your computer looking for old, buggy software, Secunia had no choice but issue it as a signed applet.
Before running the Secunia Online Software Inspector (or any signed applet), a warning is issued that it will run with "unrestricted access" and asking for confirmation that this is OK. A screen shot of this warning is shown below.
A signed Java applet includes a bunch of bits known as a digital certificate. When we say that an applet is signed, we mean that it includes a certificate. The certificate is issued by one of hundreds of Certificate Authorities, companies that make their living selling trust.
A certificate has a set lifetime. Pay more, and the certificate is valid for a longer period of time. Sometimes bad things happen to certificates and although they have not yet expired, they get revoked by the company that issued them.
On March 6th, Eric Romang reported that, by default, Java does not check if a digital certificate has been revoked. This was not a theoretical thing, he found malware that was signed with a revoked certificate.
I suppose you could nitpick whether this is, technically, a flaw. I count it as one because it opens up a security vulnerability.
The good news is that enabling a checkbox is all that's needed to have Java check for revoked certificates. In the Java Control Panel, go to the Advanced tab on turn on the checkbox for "Check certificates for revocation using Certificate Revocation Lists (CRLs)".
While you are there, a bit more security can be added by turning OFF the checkbox for "Enable granting elevated access to self-signed apps".
BUGS 9-12
The final four Java bugs were made public at the just-completed Pwn2Own contest, part of the CanSecWest security conference.
On March 6th, the first day of the contest, three new Java 7 bugs were demonstrated by three different contestants: James Forshaw, Joshua Drake and security company VUPEN.
On the second day of the contest, March 7th, Ben Murphy demonstrated yet another flaw in Java 7 Update 17 (the latest and not-so greatest).
That's our dozen.
SAFE and SECURE
This pattern, of new flaws being discovered immediately after the release of a new version of Java, has been the rule rather than the exception.
Try not to LOL the next time you install Java and see the message below about its providing "safe and secure access to the world of amazing Java content". Safe and secure? Puh-leeeeeze.
