The title of this blog is far from unique. Tracking security flaws in Java is like counting grains of sand on a beach.
As I write this on January 27, 2013, the flaw in question is new. It is known by its creator, Adam Gowdiak of Security Explorations, simply as Issue 53.
Before going into detail, let's first put things in perspective.
The last Java flaw garnered a ton of attention, with a typical headline reporting that the Department of Homeland Security told everyone to disable Java. It's not clear why that flaw garnered so much attention. The New York Times reported it as a "rare" warning, but that news was not fit to print. The warning was routine.
In the middle of the last scare, Art Manion and Will Dormann of CERT wrote
"We've been telling people to disable Java for years. In fact, the first version of the Securing Your Web Browser document from 2006 provided clear recommendations for disabling Java in web browsers."
Oracle released a new edition of Java (Version 7 Update 11) to fix that problem, very quickly (perhaps an example of what bad publicity can do). But since that fix was issued on January 13th, the bad news for Java has continued to trickle out.
MORE BAD NEWS
Initially, reports claimed that the January 13th fix was incomplete (see the home page of JavaTester.org for links). Researchers reported that a flaw remained, one that could not be directly exploited but was just sitting there waiting for someone to discover a way to exploit it. An accident waiting to happen.
On January 14th Gowdiak told Reuters that Java 7 Update 11 failed to fix several known and critical security flaws. He should know, he is, perhaps, the world record holder when it comes to finding bugs in Java.
On January 16th, Brian Krebs reported that a bad guy was selling a new bug in the just-patched edition of Java.
Less than 24 hours after Oracle patched a dangerous security hole in its Java software that was being used to seize control over Windows PCs, miscreants in the Underweb were already selling an exploit for a different and apparently still-unpatched zero-day vulnerability in Java ...
On January 17th, Trend Micro reported finding Windows based malware that tries to trick people into installing it by pretending to be "Java Update 11". So, all of us nerds that get called by non-techies asking if its OK to install the Java update their computer is suggesting, can't just blindly say yes.
Not content to merely inventory his already discovered flaws in Java, Gowdiak appears to have taken the release of Update 11 as a new challenge.
On January 18th, he reported that "two new security vulnerabilities (51 and 52) were spotted in a recent version of Java SE 7 code and they were reported to Oracle today ..."
These new flaws, like the one that got all the publicity earlier this month, permitted an unsigned* Java program embedded in a web page to break out of the normal Java sandbox and do as it pleases on the victims computer. For whatever reason, this got no publicity.
On January 21st, I wrote about the new security rules for running unsigned Java programs in web pages. While testing, I found that after disabling Java in all browsers, re-enabling it broke Internet Explorer. As a result, IE9 on Windows 7 would run unsigned Java programs, without warning, even when the security level was set to "Very High".
You may be thinking, so what? After all, this just puts Java 7 on a level playing field with Java 6, which has no rules. Still, this makes Java 7 more dangerous because all the recent flaws seem to be with features added in version 7. Even without security rules, Java 6 still seems to be safer.
On January 22nd, Ed Bott took A close look at how Oracle installs deceptive software with Java updates. While he does not describe a security flaw per se, it is nonetheless a useful warning for anyone using Java on Windows. Bott wrote a great article, but left out two points.
First, Oracle has versions of Java that can be downloaded that do not contain extra add-on software (version 7 here, version 6 here). Second, the safest way to upgrade to a new release of Java on Windows is to uninstall the software first, then do a new installation.
On January 25th, Computerworld reported that Oracle's head of Java security, Milton Smith, promised to do better going forward. Mr. Smith cited new "very significant" security improvements in Java, but griped that since the features are new, few people understand them (anyone wishing to understand them, can see my previous blog: Understanding the new security in Java 7 Update 11).
JAVA FLAW NUMBER 53
And that's where things stood until today, when I received an email from Adam Gowdiak pointing me to his latest discovery of, yet another Java bug. Ironically, the bug is with the new security improvements Mr. Smith alluded to.
As is the normal pattern, this new flaw involves running unsigned Java programs embedded in web pages.
Java 7 Update 10 introduced the new security rules for unsigned applets, and Update 11 made the default more secure. But, it turns out that the rules are not rules, they're not even suggestions. Gowdiak referred to them as theories.
He writes
What we found out and what is a subject of a new security vulnerability (Issue 53) is that unsigned Java code can be successfully executed on a target Windows system regardless of the four Java Control Panel settings ...
Whereas I found that Internet Explorer would ignore the new security rules, Gowdiak's discovery is much broader. We approached things differently. I tested with safe Java applets, he purposely wrote a malicious one.
Via email, Gowdiak wrote that "We found a generic way to bypass the new security settings imposed by Java Control Panel that control the launch of unsigned Java code."
In other words, his malicious unsigned applet can do its dirty work in all browsers. On Windows 7, he tested the latest version of Internet Explorer 9, Firefox 18.0.1, Opera 12.12 and Google Chrome 24.0.1312.56m.
Also, since I was using safe applets, Java had to be tweaked a couple times before the rules were ignored (the end user had to first disable Java in browsers via the Java Control Panel, then later re-enable it). Not so with Gowdiak's malicious applet, which can run without warning on the "Very High" setting, even if Java has not been tweaked and even if the "Very High" setting is blocking other applets.
In the conclusion of his Full Disclosure mailing list posting, Gowdiak wrote
"... recently made security "improvements" to Java SE 7 software don't prevent silent exploits at all. Users that require Java content in the web browser need to rely on a Click to Play technology implemented by several web browser vendors in order to mitigate the risk of a silent Java Plugin exploit."
Sadly, that advice is only useful to techies that understand both Java and Click-to-play. In my opinion, non-techies are best served by a Chromebook which is easy to use, requires no maintenance, will never get a virus and doesn't do Java.
As for Windows and Mac users, the long-standing best strategy is to un-install Java and hope that nothing breaks. Anyone that does need Java, for either a website or an installed application, should read my recent blog How to be as safe as possible with Java.
Yesterday, I first heard the satiric definition of Java - Just Another Vulnerability Announced. Today, it's true.
*For an explanation of signed vs. unsigned Java programs, see my previous blog.