By now you've heard about the latest, very serious problem with Oracle's Java runtime. You may also have heard that it could take a very long time to fix. Here's why: The flaw uncovered by security researchers last week devolves not to one issue, but to a series of issues, one knocking into the other like dominoes. Oracle has fixed one of the dominos with a patch, but there are likely to be other ways to tip over the entire row.
The vulnerability patched by Oracle resides in a version of Java 7 designed to extend Web browsers. The defect made it possible for a malicious Java applet on a Web page to execute arbitrary code on the underlying computer.
While this sort of defect would usually be kept secret until a fix was available, it was disclosed last week because malicious crackers had already found the defect and were exploiting it as part of a dirty-tricks toolkit used by scammers and other thieves, giving Oracle zero days to fix the code. As more researchers evaluated this "zero-day exploit," it became clear it was exceptionally serious.
With terrific speed, Oracle's engineers created a fix for the problem over the weekend and released it Monday. Yet security researchers weren't impressed. Why was that? I asked Oracle to brief me, but I was refused and simply referred to a blog posting on the subject, which offered little explanation.
Instead I turned to the open source community for help. Java 7 is actually based on an open source project called OpenJDK, and Oracle had also released patches for that. I was able to quickly find explanations of both the defect and the fix.
Running arbitrary code via Java in a browser is supposed to be impossible, because of a feature known as the "Java sandbox." Capabilities of Java that affect the machine it's running on are restricted to apps that have gained necessary permissions from the machine owner. To reach outside the sandbox and touch the machine -- including to run arbitrary code -- involves getting permission from a part of the Java runtime called the Security Manager.
Oracle has prevented the exploit from succeeding in an emergency release by fixing just the defective new implementation of invokedynamic. A bug allowed "reflection" -- the runtime discovery of the characteristics of classes -- to disclose inner details of Java classes that should have been hidden. That's been fixed, but there don't seem to have been changes to the other subsystems used in the exploit.
That means there's every chance that crackers could find a new way to exploit the same defects. Those other subsystems interact with each other and with the Security Manager in subtle, complex ways, and it's perfectly reasonable for the software engineers creating the emergency fix to have decided not to mess with them for fear of creating worse issues than they were solving.