Why fixing the Java flaw will take so long

Oracle isn't saying much, but the OpenJDK community has provided InfoWorld with a complete analysis -- and a critique of Oracle's patch

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.

Emergency response

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.

Problem analysis
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.

But this exploit was able to bypass the Security Manager and gain permission to access the machine. A combination of subsystems -- including JMXBeanServer, the Rhino JavaScript classloader, and the new invokedynamic support that was added in Java 7 -- were used in a way very similar indeed to a previously reported defect that had not been completely fixed back in August.

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.

1 2 Page
Join the discussion
Be the first to comment on this article. Our Commenting Policies