Security Aspects in

Java Bytecode Engineering(Blackhat Briefings 2002, Las Vegas, Aug 01,02)

Marc SchönefeldSoftware-Architect

schonef@acm.org

2

Agenda

• Java Security Architecture: an Overview

• The JVM: Structures and Concepts

• Bytecode Basics

• Bytecode (Reverse) Engineering

• Applications of Bytecode (Reverse)

Engineering

3

Java SecurityJava Security Architecture: Architecture: an overviewan overview

5

How the court defines JavaFindings of Judge Thomas Penfield Jackson, Nov. 5, 1999

• 73. The term "Java" refers to four interlocking elements.

• First, there is a Java programming language with which developers can write applications.

• Second, there is a set of programs written in Java that expose APIs on which developers writing in Java can rely. These programs are called the "Java class libraries."

• The third element is the Java compiler, which translates the code written by the developer into Java "bytecode."

• Finally, there are programs called "Java virtual machines," or "JVMs" which translate Java bytecode into instructions comprehensible to the underlying operating system.

6

Java Architectural Stack

Hardware

Operating System

Java Virtual Machine

Standalone JRE,J2SE Web Start

Application

Browser JRE

Applet

J2EE App-Server

EJBeansServlets, JSP

7Runtime

Development

The typical JVM development environment

Dog.java

Cat.py

Bird.jJVM

Dog. class

Cat.class

Bird.class

jython

String systemclass

Objectsystemclass

<other>Systemclass

Classloader

Classloader

Classloader

SystemClassloader

VERIFIER

JASM

Javac/jikes

8

The basic security architecture

• Java security (APIs)– (access): The Security manager– (origin): Signed Codebases– (behalf): Principle-based access control (JAAS)– cryptography

• JVM security– Class loaders – Class file verification process– JVM intrinsic security features

9

Java security Security Manager and its API

• Central instance for access control as far as code is concerned

• Policies define access to outer-domain ressources

• SecurityManager objects instances enforce policies, throwing SecurityExceptions

• By Default java programs do not have a security manager, therefor it is a good precaution to instantiate one

10

Java security Security Manager and its API

• Fine-grained control to Limit access on:– SocketConnections (create, accept, multicast)– Thread Groups– Dynamic Library Loading (JNI)– Files (read, write, delete)– Access to External shared ressources (printjob,

clipboard)– Program control (exit, toplevelwindow)– Runtime components (member, package,

classloader)

11

Java security Code Base Authentication

• Java-Archives (JARs) store codebases• Proof of Origin can be be achieved by

signing the jars

JAR

Cat.classDog.classBird.class

Privatekey

hash

sign

JAR

Signed hash

Cat.classDog.classBird.class

12

Java security JAAS: Security based on principals

• Enables login functionality– Username, password– Fingerprint – ...

• Execution permitted/denied depending on the identity who runs the code– Policy based access to functionality– Fine-grained permission handling possible

13

JVM securityintrinsic features

• Non-continuous memory model, distinct data areas– Java stack frames (execution state)– Method area (bytecode storage)– Garbage-collected heap (object storage)

• Type-safe casting • No self-modifying code• Automated garbage-collecting disallows explicit

free operation• Automatic Array bounds-checking prevents

off-by-one and buffer overflow scenarios

14

JVM security Class loaders

• Classloaders load a classfile as byte array into the JVM

• Can load from – file, – network or – dynamically generated byte array – Can even compile on the fly (so Java behaves like

Perl)

• Security features– Establishing name spaces– Enforcing separation of trusted system library code

from user-supplied code via parent-delegation

15

JVM security Verifier

• Task: check loaded classfile for integrity

• 4-step process– 1st step: structural correctness– 2nd step: data type correctness– 3rd step: bytecode checks– 4th step: symbolical references

management (runtime)

16

JVM

JVM

CA FE BA BE 00 03 00 2D00 13 07 00 17 12 30 11.. .. ..

JVM security Classfile verification

public class Cat { void bite (int times) { ... }}

public class Cat { void bite (int times) { ... }}

.class public Dog

.method bite I

.invokestatic seekVictim

...

.end method

.end class

.class public Dog

.method bite I

.invokestatic seekVictim

...

.end method

.end class

CA FE BA BE 00 03 00 2D00 13 07 00 17 12 30 11.. .. ..

CA FE BA BE 00 03 00 2D00 13 07 00 17 12 30 11.. .. ..

VerifierVerifierPASS

1

PASS

1

PASS

2

PASS

2

PASS

3

PASS

3

PASS

4

PASS

4

ClassloaderClassloader

JAVACJAVAC

bytecode assemblerbytecode assembler

17

The Verification Process Pass 1: Basic Structural checks

• the classloader delivers byte array• Magic number = 0xCAFEBABE ? • Version id: 1.1=45.3, 1.2=46.0, 1.3=47.0,

1.4=48.0• All recognized attributes need to be in

proper length• The class file must not be truncated or have

extra bytes at the end• The constant pool must not contain any

„superficially unrecognizable information“

18

The Verification ProcessPass 2: Check Context-Pool (CP) information

• final classes are not subclassed, and final methods are not overridden.

• All classes (except java.lang.Object) must have a superclass.

• Check constraints for CP-entries: For example, class references in the CP can be resolved via a field to a string reference in the CP.

• Checking that all field references and method references in the CP must have legal names, classes, and type signature.

19

The Verification ProcessPass 3 : Bytecode verification

• Core part of verification• Static constraints

– Checking maximal local variable count throughout control flow

– Checking control-flow correctness (branch always to start of instruction, not beyond end of code)

– all exception-handlers are valid (no partial overlap)– ...

• Structural constraints – Reachability : subroutines (scope), exception

handlers– data-flow : Instances initialization and new objects,

stack size

20

The Verification ProcessPass 4: delayed checks during runtime

• Verifies that currently executing class is allowed to reference the given class.

• The first time an instruction calls a method, or accesses or modifies a field, the verifier checks the following: – method or field class– Method or field signature– that the currently executing method has

access to the given method or field• insert „quick“ optimized instructions

21

Problems with JDK verifierNot enabled by default

public class IllegalAccess2{public String str = "The trade secret";public void test(){System.out.println("Test2: " + str);}

}

public class IllegalAccess2{public String str = "The trade secret";public void test(){System.out.println("Test2: " + str);}

}

public class IllegalAccess{public static void main(String args[]){

IllegalAccess2 t2 = new IllegalAccess2();System.out.println("Test1: " + t2.str);t2.test();t2.str = "an open hint";System.out.println("Test1: " + t2.str);System.exit(0);

}}

public class IllegalAccess{public static void main(String args[]){

IllegalAccess2 t2 = new IllegalAccess2();System.out.println("Test1: " + t2.str);t2.test();t2.str = "an open hint";System.out.println("Test1: " + t2.str);System.exit(0);

}}

D:\entw\java\blackhat>java -classpath . IllegalAccessTest1: The trade secretTest2: The trade secretTest1: an open hint

D:\entw\java\blackhat>java -classpath . IllegalAccessTest1: The trade secretTest2: The trade secretTest1: an open hint

22

Problems with JDK verifierNot enabled by default

public class IllegalAccess2{private String str = "The trade secret";public void test(){System.out.println("Test2: " + str);}

}

public class IllegalAccess2{private String str = "The trade secret";public void test(){System.out.println("Test2: " + str);}

}

public class IllegalAccess{public static void main(String[] args){

IllegalAccess2 t2 = new IllegalAccess2();System.out.println("Test1: " + t2.str);t2.test();t2.str = "an open hint";System.out.println("Test1: " + t2.str);System.exit(0);

}}

public class IllegalAccess{public static void main(String[] args){

IllegalAccess2 t2 = new IllegalAccess2();System.out.println("Test1: " + t2.str);t2.test();t2.str = "an open hint";System.out.println("Test1: " + t2.str);System.exit(0);

}}

Variable str now restricted, JVM should now complain access, but at least on JDK1.3.1 and 1.4.0_01 2000 the following happens...

23

Problems with JDK verifierNot enabled by default

D:\entw\java\blackhat>java IllegalAccessTest1: The trade secretTest2: The trade secretTest1: an open hint

D:\entw\java\blackhat>java IllegalAccessTest1: The trade secretTest2: The trade secretTest1: an open hint

D:\entw\java\blackhat>java -verify IllegalAccess

Exception in thread "main" java.lang.IllegalAccessError: try to access field IllegalAccess2.str from class IllegalAccess

at IllegalAccess.main(IllegalAccess.java:7)

D:\entw\java\blackhat>java -verify IllegalAccess

Exception in thread "main" java.lang.IllegalAccessError: try to access field IllegalAccess2.str from class IllegalAccess

at IllegalAccess.main(IllegalAccess.java:7)

Only the explicit -verify flag restricts access to restricted variable „str“ !

24

Problems with Inner classes

• Inner classes can access private fields of outer classesfinal class Outer {

private String secret = "you will never be able to read this" ;public void alter_secret(String x) {

secret = x; }

private String reverseSecret() {StringBuffer b = new StringBuffer(secret);return b.reverse().toString();

}

class Inner {private String innersecret = secret;

private String reverseinner = reverseSecret();}

public static void main(String[] args) {Outer outer = new Outer();

}}

final class Outer {private String secret = "you will never be able to read this" ;public void alter_secret(String x) {

secret = x; }

private String reverseSecret() {StringBuffer b = new StringBuffer(secret);return b.reverse().toString();

}

class Inner {private String innersecret = secret;

private String reverseinner = reverseSecret();}

public static void main(String[] args) {Outer outer = new Outer();

}}

new

25

Problems with Inner classes

• You can‘t access these private fields from other classes via java code, but you can with a handcrafted bytecode classnew Outerdupinvokespecial Outer/<init> ()V // new Outerdup // dup here to avoid local vars, take it directly from stack dupinvokestatic Outer/access$000 (LOuter;)Ljava/lang/String; getstatic java/lang/System/out Ljava/io/PrintStream;swap // correct the positionsinvokevirtual java/io/PrintStream/println (Ljava/lang/String;)Vinvokestatic Outer/access$100 (LOuter;)Ljava/lang/String; getstatic java/lang/System/out Ljava/io/PrintStream;swap // correct the positionsinvokevirtual java/io/PrintStream/println (Ljava/lang/String;)Vreturn

new Outerdupinvokespecial Outer/<init> ()V // new Outerdup // dup here to avoid local vars, take it directly from stack dupinvokestatic Outer/access$000 (LOuter;)Ljava/lang/String; getstatic java/lang/System/out Ljava/io/PrintStream;swap // correct the positionsinvokevirtual java/io/PrintStream/println (Ljava/lang/String;)Vinvokestatic Outer/access$100 (LOuter;)Ljava/lang/String; getstatic java/lang/System/out Ljava/io/PrintStream;swap // correct the positionsinvokevirtual java/io/PrintStream/println (Ljava/lang/String;)Vreturn

new

26

Other Problems with JDK verifier

• SDK and JRE 1.3.1_01 or earlier– „A vulnerability in the Java(TM) Runtime

Environment Bytecode Verifier may be exploited by an untrusted applet to escalate privileges. „

• Also some Netscape browser versions were affected

27

Problems with JDK verifier

• You can check your classes with a standalone verifier

• Open source solution „Justice“ supplied in Apache Jakarta project BCEL

new

28

Problems with Java securityWhat is also still missing

• Checks in terms of hard and soft limits on– memory allocation

– Thread activation

• Excessive memory usage and threading utilization often leads to Denial of Service problems

29

The JVM: The JVM: Structures Structures

andandConceptsConcepts

30

JVM Internals

• The architecture– JVM is an abstract concept– Sun just specified the interface– implementation details depend on specific

product (SUN JDK, IBM JDK, Blackdown)

• Java bytecode, the internal language– independent from CPU-type (bytecode)– Stackoriented, object-oriented, type-safe

31

Runtime view on a JVM

ClassloaderClassloader

Ru

ntim

e D

ata

sto

rag

eR

un

time D

ata

sto

rag

e

MethodArea (Classes)

Heap (Objects)

Stack Frames

PC registers

Native method stacks

JVMruntime

JVMruntime

NativemethodsNative

methods

32

Runtime data

• Frame: • Saves runtime state of execution threads,

therefore holds information for method execution (program counter)

• All frames of a thread are managed in a stack frame

33

Runtime data

• Method area– Runtime information of the class file– Type information– Constant Pool– Method information– Field information– Class static fields– Reference to the classloader of the class– Reference to reflection anchor (Class)

34

The Constant Pool

• The "constant pool" is a heterogenous array of data. Each entry in the constant pool can be one of the following: – string , class or interface name , reference to a

field or method , numeric value , constant String value

• No other part of the class file makes specific references to strings, classes, fields, or methods. All references constants and also for names of methods and fields are via lookup into the constant pool.

35

The Class File Structure

HEADER

CONSTANT-POOL

ACCESS FLAGS

(Final, Native,Private,

Protected,...)

INTERFACES

FIELDS METHODS

ATTRIBUTES

• You can use a classdumper like javap -c or DumpClass to analyze these inner details

36

The Class File Format

• Java class files are brought into the JVM via the classloader

• The class file is basically just a plain byte array, following the rules of the byte code verifier.

• All 16-bit and 32-bit quantities are formed by reading in two or four 8-bit bytes, respectively, and joining them together in big-endian format.

37

Methods and Fields

• The type of a field or method is indicated by a string called its signature.

• Fields may have an additional attribute giving the field's initial value.

• Methods have an additional CODE attribute giving the java bytecode for executing that method.

38

The CODE Attribute

• maximum stack space • maximum number of local variables • The actual bytecode for executing the

method. • A table of exception handlers,

– start and end offset into the bytecodes, – an exception type, and – the offset of a handler for the exception

39

Bytecode Bytecode BasicsBasics

40

The JVM types

• JVM-Types and their prefixes– Byte  b – Short  s – Integer  i  (java booleans are mapped to jvm

ints!)– Long  l – Character  c– Single float f – double float d – References a  to Classes, Interfaces, Arrays

• These Prefixes used in opcodes (iadd, astore,...)

41

The JVM Instruction Mnemonics

• Shuffling (pop, swap, dup, ...)• Calculating (iadd, isub, imul, idiv, ineg,...)• Conversion (d2i, i2b, d2f, i2z,...)• Local storage operation (iload, istore,...)• Array Operation (arraylength, newarray,...)• Object management (get/putfield,

invokevirtual, new)• Push operation (aconst_null, iconst_m1,....)• Control flow (nop, goto, jsr, ret, tableswitch,...)• Threading (monitorenter, monitorexit,...)

42

Bytecode

• Java Bytecode (JBC) are followed by zero or more bytes of additional operand information.

• Table lookup instructions (tableswitch, lookupswitch) have a flexible length

• The wide operation extension allows the base operations to use „large“ operands

• No self-modifying code• No branching to arbitrary locations, only to

beginning of instructions limited to scope of current method (enforced by verifier!)

43

Bytecode Bytecode (Reverse)(Reverse)

EngineeringEngineering

44

Bytecode Engineering tools

• Obfuscators – Remove/Manipulate all information that can be

used for reverse engineering

• Native compilers – „Real“ compile of java bytecodes to native

instructions (x86/sparc)

• Build your own bytecode– Programmatic Generation – Manipulate classfiles with an API

45

ObfuscatorsTechniques used

• Identifier Name Mangling • The JVM does not need useful names for

Methods and Fields • They can be renamed to single letter identifiers

• Constant Pool Name Mangling• Decrypts constant pool entries on runtime

• Control flow obfuscation• Insertion of phantom variables, stack scrambling • And by relying on their default values inserting

ghost branch instructions, which never execute

46

ObfuscatorsProblems with Obfuscation

• Constant value Mangling implies overhead processing in extra method call of an „deobfuscatename“ method in each retrieval from constant pool

• Dynamic class loading may become broken as classes get new names and reflection calls like class.forName(„Account“) will fail because class „Account“ now known as by it‘s obfuscated name „b16“!

• And: Obfuscation breaks patterns that can be recognized by JIT-engines for optimization

48

Protecting the Source Code:Native Compilers

• Convert Java bytecode to C• Generate executable via normal c-build

fast executionAdditional decompilation effort needed Long turnaround timesEven for small java programs you get monster

size executable files (67mb source for Viva.java) from some commercial products

Transformed program may than be vulnerable to buffer overflows and off-by-ones

49

Bytecode Reverse Engineering

• Decompilation– Get Source code from class files

• Graphical Analysis– Rebuild the logical control flow

• Disassembly– Get symbolic bytecode from class files

50

Decompilers

• Several available, – MOCHA , by Hanpeter van Vliet was the first

one– JASMINE , patch of Mocha - crashed less often– JAD, the fast Java Decompiler (written in C++)

by Pavel Kouznetsov is quite usable, but can also be fooled

• DJ JAVA , GUI for JAD• NMI, GUI for JAD

But only one really works

51

Decompilers

• General method of decompilation– Rebuilding control flow from class file code

segment– Matching flow patterns to java language

contructs– Associating constants and external references

from constant pool entries – Do not redo field/method and constant pool entry

mangling– Condensed constant pool entries therefore

sometimes result in non-valid java identifiers in the generated source

52

Graphical AnalysisOverview

• All Java Classfiles (those which are obfuscated, too) have to be compliant to the JVM specification

• Although Control flow is interleaved in the obfuscated class file, a graphical flow reveals most of the original control flow

• The inner structures and dependencies of the methods can be discovered by graphical analysis

53

54

Graphical AnalysisTools

• BCEL: Byte-Code Engineering Library– Written by to Markus Dahm– Maintained by the Apache Jakarta Project– Exposes internal structure of *.class files

as java objects• aiSee: graphical visualisation tool

– Cross-platform– Developed by the university of saarland– Uses graphical description language

55

Graphical AnalysisProcedure

• Walk thru a specific code attribute of methods in a classfile

• Retrieve target instructions• Calculate control blocks• Calculate successor relationships• Rebuild control flow • Export control flow graph (CFG) as GDL• Display the GDL file for the control flow

in aiSee

56

Disassembling

• Javap– The disassembler from the JDK

• Gnoloo– disassembler by Joshua Engel from

„Programming for the JVM“ (ISBN: 0201309726)

– Can be used in pair with Oolong, the corresponding assembler

– Comes with a good DumpClass tool

57

Applications of Applications of Bytecode Bytecode (Reverse) (Reverse)

EngineeringEngineering

59

Build your own bytecodeTools

• Javac & Javap– Included in the JDK – Shows you how to translate high

language constructs to bytecode• Hex-Editor for binary patching

– Ultraedit or Xemacs

• Oolong/Gnoloo – Assembler and disassembler

• BCEL

60

Managing the Bytecode with BCEL

• BCEL comes with several tools– org.apache.bcel.util.Class2HTML

• Generates nice HTML pages for a class

– org.apache.bcel.util.JavaWrapper• Replaces standard java interpreter to use own

class loader• Lets you modify a loaded class via modifyClass

method, that can be overloaded

– org.apache.bcel.verifier.GraphicalVerifier• Allows you to verify your class files with verbose

output

61

Binary Patching with your favorite editor

• Read the output of „javap –c“ or DumpClass• You got to know the opcodes values to find the

injection point• Possibilities:

– so you can blank out some unwanted code with 00 00.. (nop)..

– Adjust some binary checks– For example x9a0016 to x570000 („ifne +22“ to

„pop nop nop“)

• Remember to keep the right balance on the stack

62

Sample bytecode The java source

public class Viva {

public static void main(String[] args) {

String[] TOTD = {"Viva","Las","Vegas"};

for (int i = 0; i < TOTD.length; i++) {

new Viva(TOTD[i]);

}

}

public Viva(String a) {

System.out.println(a.toUpperCase());

}

}

63

Sample bytecode The disassembled Viva bytecode (Gnoloo) –I-

.method public static main ([Ljava/lang/String;)V

.limit stack 4

.limit locals 3

.line 3iconst_3anewarray java/lang/Stringdupiconst_0ldc "Viva"aastoredupiconst_1ldc "Las"

aastoredupiconst_2ldc "Vegas"aastoreastore_1

.line 4iconst_0

istore_2goto l39

.line 5l25:

new Vivadupaload_1iload_2aaloadinvokespecial Viva/<init> (Ljava/lang/String;)Vpop

.line 4iinc 2 1

l39: iload_2aload_1arraylengthif_icmplt l25

.line 7return

64

Sample bytecode The disassembled Viva bytecode (Gnoloo) –II-

.method public <init> (Ljava/lang/String;)V

.limit stack 2

.limit locals 2

.line 8

aload_0

invokespecial java/lang/Object/<init> ()V

.line 9

getstatic java/lang/System/out Ljava/io/PrintStream;

aload_1

invokevirtual java/lang/String/toUpperCase ()Ljava/lang/String;

invokevirtual java/io/PrintStream/println (Ljava/lang/String;)V

.line 10

return

.end method

65

Analysis of some obfuscator‘s work

DEMODEMO

public class a extends java.lang.Object { public class Viva extends java.lang.Object {

public static boolean a; public static boolean b;

public static void main(java.lang.String[]); public static void main(java.lang.String[]); public a(java.lang.String); public Viva(java.lang.String);

} }

Method void main(java.lang.String[]) Method void main(java.lang.String[]) 0 getstatic #42 <Field boolean b>

3 istore_3 4 iconst_3 0 iconst_3

5 anewarray class #1 <Class java.lang.String> 1 anewarray class #1 <Class java.lang.String> 8 dup 4 dup

9 iconst_0 5 iconst_0 10 ldc #2 <String "cLxt"> 6 ldc #2 <String "Viva">

12 invokestatic #61 <Method java.lang.String deobfuscateName(java.lang.String)> 15 aastore 8 aastore

16 dup 9 dup 17 iconst_1 10 iconst_1

18 ldc #3 <String "yD"> 11 ldc #3 <String "Las"> 20 invokestatic #61 <Method java.lang.String deobfuscateName(java.lang.String)>

23 aastore 13 aastore 24 dup 14 dup

25 iconst_2 15 iconst_2 26 ldc #4 <String "c@t"> 16 ldc #4 <String "Vegas">

28 invokestatic #61 <Method java.lang.String deobfuscateName(java.lang.String)> 31 aastore 18 aastore

66

Things you can only do in JBCmethods that only differ in return type!

.class public overload

.super java/lang/Object

.field static myint I

.field static mydouble D

.method static jvmoverload ()I

.limit stack 3

.limit locals 1 iconst_1 ireturn

.end method

.method static jvmoverload ()D

.limit stack 3

.limit locals 1 dconst_1 dreturn

.end method

.method public static main ([Ljava/lang/String;)V

.limit stack 3

.limit locals 1invokestatic overload/jvmoverload ()Iputstatic overload/myint Iinvokestatic overload/jvmoverload ()Dputstatic overload/mydouble Dreturn

.end method

.end class

67

Things you can only do in JBCmethods that only differ in return type!

If the decompiled source is compiled again:

• The signatures are considered duplicate in java• But valid in java bytecode, and therefore can be used in

obfuscation techniques

>javac -classpath . overload.javaoverload.java:15: jvmoverload() is already defined in overload static double jvmoverload() ^1 error

68

DEMODEMO

69

Usage Patterns

• Scenarios– Tools for database access – Adding dynamically Logging, profiling

facilities without changing sourcecode – Verifying class files on domain boundaries

(add-in to content filtering systems)– Find Frontier bugs, before they may be

exploited for DoS-attacks by calling code which crashes the JVM

– Port your own language to Java bytecode

70

Java Library Holes

• In JNI-based applications checking for null pointers is often given too little regard

• Also the routines in the core Java Runtime classes use native code (included in jvm.dll)

• But not every entry into these trusted libs is shielded appropriatly

• In some cases you can force a JVM crash when pumping „null“ values to that routines

71

Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x6d443081Function name=JVM_DisableCompilerLibrary=H:\programme\JB6\jdk1.3.1\jre\bin\hotspot\jvm.dll

Current Java thread:at sun.dc.pr.PathDasher.cInitialize(Native Method)at sun.dc.pr.PathDasher.<init>(PathDasher.java:48)at crashtest.CrashTest.<init>(CrashTest.java:91)at crashtest.CrashTest.main(CrashTest.java:98)

Dynamic libraries:0x00400000 - 0x00405000 H:\programme\JB6\jdk1.3.1\bin\javaw.exe0x77F40000 - 0x77FF0000 C:\WINDOWS\System32\ntdll.dll.... 0x76BB0000 - 0x76BBB000 C:\WINDOWS\System32\PSAPI.DLL

Local Time = Sun Jun 23 14:00:38 2002Elapsed Time = 0## HotSpot Virtual Machine Error : EXCEPTION_ACCESS_VIOLATION# Error ID : 4F530E43505002CC# Please report this error at# http://java.sun.com/cgi-bin/bugreport.cgi## Java VM: Java HotSpot(TM) Client VM (1.3.1-b24 mixed mode)## An error report file has been saved as hs_err_pid3888.log.# Please refer to the file for further information.

#

Frontier BugsSample

package crashtest;import sun.dc.pr.PathDasher;public class CrashTest{ public CrashTest() { PathDasher d = new PathDasher(null); } public static void main(String args[]) { CrashTest crashTest1 = new CrashTest(); }}

72

Frontier BugsLocalization

• This possible vulnerability may also be harmful in other tools as if they rely on JNI (native interface) classes calling to some native core (written in some appropriate language, C or C++)

• Example JDK: The frontier between – java library code (rt.jar) and the – jvm (jvm.dll, libjvm.so)

has official and inofficial entrypoints– The official ones are called by Native

Java-routines recommended by Sun (java.*) – The inofficial are called by sun.* routines

73

Frontier BugsSemiautomatic Detection

• Traverse java runtime libraries• Procedure

– Detect public classes

– In the public classes detect public methods

– From that filter native methods

– Now you have a list containing the public entry points to

the JVM library or another JNI-library

• Tool: NativeFinder, which is based on BCEL

74

Frontier Bugs Semiautomatic Detection

• On this list:– Start with the static class methods, they are

easier to test– With the object methods, you need to know how

to build such on object• In the easy case you have an default constructor • In the hard case you will have to delve deep into the

class hierarchy to get an object

– Then call the method with some nice „null“ values and wait

75

DEMODEMO

76

Soon to become a problem: Hot Swap

• Until JDK 1.3 class definitions were immutable during the lifetime of a JVM

• JDK 1.4 now offers a „hot swap“ of class definitions via JVMDI (debugger API)

• Now you (or someone else?) can „substitute your class definitions by modified code in a running application through the debugger“

77

Q&AQ&AMail to schonef@acm.org for the tools

Or visit our website http://www.illegalaccess.org/

for some more examples and links (sept 02)

78

Thank Thank you!you!

To You as a great audience, To The Blackhat Staff (specially Charel for the tickets),

To Halvar, Johnny and G0dzilla for the helpful discussions,And to my Girlfriend