Tim Boudreau is a noted technology consultant, evangelist and author. While perhaps most broadly known for his leadership on Sun Microsystems’ NetBeans, those who’ve worked with Tim remark most on his technical chops, passion for a great challenge and rare gift of great communication. And, as a former troubadour, he’s pretty tough when it comes to bad 70s rock lyrics too. A real renaissance programmer. Tim has posted 25 posts at DZone. You can read more from them at their website. View Full User Profile

The Java Security Exploit in (Mostly) Plain English

01.18.2013
| 13818 views |
  • submit to reddit

Originally posted at timboudreau.com

While chatting with Simon Phipps, I read through the Java security exploit that got so much attention this week - and the patches to fix it. For anyone interested, here's a quick'n'dirty analysis (scroll down for the detailed technical analysis):

A Summary In Layman's Terms

Java applets are little programs that run on your computer, inside your web browser, just like the Javascript code that makes the modern web work the way it does. Most modern web sites, including this one, use things like that. And the reason Java applets are generally safe is that they can't go outside the "sandbox" of the Java Virtual Machine (JVM) - they can only do limited things. An applet can ask for permission to, say, read your hard drive, when it loads - at which point your browser will pop up a big "This applet wants permission to go hog-wild and do whatever it wants - do you really, really trust it?" box. And you can say NO to that.

The security problem is that someone found a way to let an applet go hog-wild on your computer without your permission. It's not news because things going hog-wild on computers is news - any of the many thousands of viruses for Windows do that. It is news because Java's record on security has been very good, making this a nasty surprise.

The Details

Specifically what the exploit does is:

  1. Create an array of bytes which is Java bytecode - a chunk of Java software that can be run. If that code runs without security checks, it can wreak whatever havoc its author wants.

  2. Create a JMX server. JMX is a server-side technology for monitoring servers, which allows server software to provide MBeans - little Java classes that let administrators monitor and remote-control their software on the server. The JMX server can be told to load a class by name - meaning it is designed (for good reason) to load a Java class it has never seen before by someone saying to it "Go find a class named MyServerThing and load it". This is the technique called "reflection".

  3. Tell the JMX server to load two classes which are part of an interpreter for the Javascript language which runs inside the Java runtime. Notably, if you're going to run a language like that and you want it to be fast, you're going to want to actually generate Java code on the fly and load that up and run it. So you're going to need a ClassLoader to do it. And sure enough, there is one.

  4. Call a chain of methods, using reflection and the relatively new MethodHandle reflection object which lets you call ad-hoc methods - to get the JMX bean loader to actually make an instance of the classloader for Javascript which is there to load on-the-fly-created Javascript stuff.

  5. Once it's gotten the JMX server to create the ClassLoader which will load ad-hoc bytes, the security breach is accomplished. It calls defineClass, whcih actually lets you pass in an array of bytes and get back a Class object (the final line of the exploit, Class.newInstance() is actually gratuitous - the exploit could just be done in the class' initializer)

Reflection - the ability to poke around in and call code your program didn't know about when it was compiled - is an old technology, and can be secured. The thing that actually got exploited was a new addition to the reflection API, which lets you call code in a new way - that is what was used to bypass security checks. MethodHandle is very necessary both for interpreted languages to run better on a JVM and for future features that will keep Java itself competitive.

There probably is something to worry about with MethodHandle and the new invoke dynamic instruction, since it is a new way to call any code anywhere in the JVM. On the other hand, there are a handful - a small and finite number - of choke-points to intercept such an attack. They are those calls that allow you to actually tell a JVM "these bytes are Java code" and have it actually load them. If you secure that, you've put most of the issue to bed. Java has had the ability to secure that for many, many years, so it's reasonable to expect this particular flavor of exploit to be locked down well and truly.

The fix released today fixes the immediate exploit. A proper fix would sit in the critical path between any code and ClassLoader.defineClass(). It is reasonable to get a minimal fix out fast. Doing anything that touches the way every byte of Java code gets loaded is not something you can do without heavy testing. So, kudos to Oracle for quashing the immediate problem, and being conservative about what kind of fix can be done quickly with low liklihood of unintended consequences. But they should do a more thorough fix.

I agree with critics who say there are a lot of subsystems interacting here - pieces of applets, JMX and a scripting language interpreter were combined in a novel way to create an exploit.

I disagree with the critics who say that there is so much complex interplay that the problem will not give way to analysis without weeks or months of study. All you have to care about to fix something like this are the choke-points that any code which tries to load bytecode must pass through. This kind of apocalyptic punditry seems more like a way to simultaneously look good, make news and be intellectually lazy. We're talking about a finite amount of code well within the capacity of a capable programmer's understanding.

All That Being Said...

I smell a whiff of nasty industry politics in this. At least I suspect getting Homeland Security to announce "don't use Java" was a coup for somebody, who is celebrating a bonus or popping the cork on a champagne bottle or both. If a Java exploit is a national security threat, then considering the history of Windows and what virii have cost there, there ought to be an airlift of developers from Redmond to Gitmo in leg-irons.

Published at DZone with permission of its author, Tim Boudreau. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Steven Webber replied on Mon, 2013/01/21 - 5:53am

Thank you for a well rounded and informative article. First one I've read on the exploit that actually has the details and doesn't paint Java as the enemy.

Kenneth Muhia replied on Wed, 2013/01/23 - 5:47am

Great article, it is very informative and provides great clarity on exact issue.

Rob Mitchell replied on Wed, 2013/01/23 - 1:17pm

Thanks for the update. I never really bothered with the whole witch-hunt 'cause, well, I haven't written an Applet in many years but its great that Oracle/Sun is keeping on top of things.


Reza Rahman replied on Thu, 2013/01/24 - 5:32pm

The lead for Oracle Security Martin Smith and Doland Smith from the OpenJDK team had a conference call with worlwide JUG leaders. The recordings of the meeting is available here: http://java.net/projects/jugs/downloads/download/Jan24_JUGLeaderCall.mp3. This was a frank two-way discussion with Java community leaders about Java security, bundled software installers, openness, communication and the technical/journalistic quality of recent press coverage in some venues. As Donald and Martin indicate on the call, we can expect this to be the tip of the iceberg of what will be done on the Java Security and communication fronts.

All views voiced are my own, not necessarily Oracle's.


May Hasty replied on Fri, 2013/10/11 - 11:24pm

Thank you for a well rounded and informative article. First one I've read on the exploit that actually has the details and doesn't paint Java as the enemy.

what penny stocks are hot 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.