LowLevel Security of Java Language - PowerPoint PPT Presentation

1 / 39
About This Presentation
Title:

LowLevel Security of Java Language

Description:

11/21/09. Morehouse College, Department of Computer Science. 1. Low-Level Security of Java Language. Ahmad ... System.out.println(local1) return 0;} } 11/21/09 ... – PowerPoint PPT presentation

Number of Views:52
Avg rating:3.0/5.0
Slides: 40
Provided by: Rom85
Category:

less

Transcript and Presenter's Notes

Title: LowLevel Security of Java Language


1
Low-Level Security of Java Language
  • Ahmad Ghafarian, Ph.D.

2
Java Security Issues
  • Platform Security
  • Cryptography
  • Authentication and Access Control
  • Secure Communications
  • Public Key Infrastructure (PKI)

3
Platform Security
  • Low-Level Features
  • Strong data typing
  • Automatic memory management
  • Bytecode verification
  • Secure class loading

4
Platform Security (2)
  • The Java compiler generates class files
  • An architecturally neutral, binary intermediate
    format.
  • Embedded in the class file are bytecodes suitable
    for VM
  • The bytecodes are executed by means of a runtime
    system
  • an emulator for the virtual machine's instruction
    set.
  • The same bytecodes can be run on any platform.

5
Platform SecurityStrong Data Typing
  • Strong type checking, e.g.
  • Uninitialized local variable cannot be used.
  • No pointers. Therefore, Java programmers cannot
    forge a pointer to memory
  • All references to methods and instance variables
    in the class file are via symbolic names
  • Private variable access is prohibited
  • All reference variables are checked for
    consistency
  • Integers cannot be converted into objects.
    Objects cannot be converted into integers.

6
Platform SecurityAutomatic Memory Management
  • Garbage collection makes Java programs both more
    secure and more robust.
  • Deallocates memory that are not needed anymore
  • It does not free memory accidentally

7
Platform SecurityBytecode Verification
  • The Verifier makes sure that the code will adhere
    to the following constraints
  • There are no stack overflows or underflows
  • All register accesses and stores are valid
  • The parameters to all bytecode instructions are
    correct
  • There is no illegal data conversion

8
Java compilation and execution process
  • The software should be of reasonable size that
    can be handled by students in one semester.
  • The software has been developed over more than 8
    years by a team of software engineers.
  • Object file of the software is available but not
    the source code.
  • The software contains user interfaces, an
    inelegant design, that make complete
    understanding impossible.

9
Java Virtual Machine Verifier

10
Some Responsibility of Verifiers
  • The information for each method includes
  • The maximum stack space needed by the method.
  • The maximum number of registers used by the
    method.
  • The actual code for executing the method.
  • A table of exception handlers.

11
Platform SecuritySecure Class Loading
  • Class loaders ensure
  • that untrusted code cannot interfere with the
    running of other Java programs.

12
Cryptography
  • Java API supports
  • a wide range of cryptographic services including
  • digital signatures
  • message digests
  • ciphers
  • message authentication codes
  • key generation
  • Java API Support
  • a wide range of standard algorithms including
  • RSA, DSA, AES, Triple DES, SHA, PKCS5, RC2, and
    RC4.

13
Authentication and Access Control
  • Authentication
  • secure login mechanisms
  • Access Control
  • allows the developer to create and administer
    applications

14
Secure Communications
  • APIs implementations supports the following
    secure communications protocols
  • Transport Layer Security (TLS)
  • Secure Sockets Layer (SSL)
  • Kerberos
  • Simple Authentication and Security Layer (SASL).
  • HTTPS over SSL/TLS is also included.

15
Public Key Infrastructure (PKI)
  • Supports the following features
  • Certificates
  • Certification Path Validators and Builders
  • Certificate Stores (Repositories)
  • java.util.Collection

16
Decompiling Java Code
  • With all these built in security
  • can we rebuild java code from .class file?
  • The answer is Yes with Decompilers

17
Java Decompilation Process (1)
Java Byte-Code malcode.class
  • Decompiler
  • Software

Java Source Code malcode.java
18
Java Decompilation Process (2)
Compiler
(Virtual) Machine Code
Source Code
Decompiler
  • Reversing the process of compilation (i.e. moving
    from machine code to source code)

19
Decompilation Process
Class File
expression recovery
Illegal Java
Legal (but ugly) Java
Code rewriting
Readable Source Code
20
Example Original Code
  • public class Sum
  • public static void main (String args)
  • int a10 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
  • int sum 0
  • int i    for (i0 i lt 10 i)
  • sum ai
  • System.out.println(sum)
  • return 0

21
Example Java ByteCode
  • 8049460 01000000 02000000 03000000
    04000000 8049470 05000000 06000000 07000000
    08000000 8049480 09000000 0a000000
  • 8048328   push   ebp 8048329   mov   
    esp,ebp 804832b   sub     0x8,esp 804832e 
      and     0xfffffff0,esp 8048331   mov   
    0x0,eax 8048336   sub     eax,esp
  • 8048338   movl   0x0,0xfffffffc(ebp)
  • 804833f    movl   0x0,0xfffffff8(ebp) 8048346
       cmpl   0x9,0xfffffff8(ebp) 804834a  
    jle      804834e ltmain0x26gt 804834c   jmp    
    8048364 ltmain0x3cgt804834e   mov   
    0xfffffff8(ebp),eax 8048351   mov   
    0x8049460(,eax,4),edx 8048358   lea    
    0xfffffffc(ebp),eax 804835b   add   
    edx,(eax)

22
Example Decompiled source code
  • public class Sum
  • int main(int argc, char argv, char envp)
  • int a10 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
    int local1 // mr280 - 8   // sumint
    local2 // mr280 - 12  // i
  • local1 0
  • local2 0    while (local2 lt 9)
  • local1 alocal2   // sum ai
  • local2              // i
  • System.out.println(local1)
  • return 0   

23
Are there any deference against Decompiler?
  • Yes we can use Obfuscation

24
Code Obfuscation
  • Transform a program so that it is more difficult
    to understand
  • The program must still produce the same results
  • It may execute slower or have additional side
    effects, due to added code.

25
Code Obfuscation tools
  • Freeware (Open Source)
  • Shareware
  • Commercial

26
Types of Obfuscation
27
Layout Obfuscations
  • alters unnecessary information for program
    execution, such as
  • identifier names
  • comments
  • Utilities are available to do that, see
  • . http//www.primenet.com/ej/index.html

28
Data Obfuscations
  • Changing the data structure of the program
  • Changing the way that data are stored in memory
    (e.g. change a local variable to global variable)
  • Data encoding changing a variables value, e.g
    an i to 8i 3
  • Data aggregation e.g. changing a one dimensional
    array to a two dimensional array.
  • Data ordering e.g. use a function f(i) to
    determine the index of an array

29
Control Obfuscations
  • Control aggregation e.g. changing functions to
    inline functions
  • Control ordering e.g. making loops backward
    instead of forward, or using do-while instead of
    for statement
  • Control computation
  • Smoke and mirrors Insert code that never be
    executed
  • High-level language breaking breaking a while
    loop and starting again
  • Control flow abstraction

30
Control flow abstraction
  • For example, add redundant termination conditions
    to the loop
  • Before
  • int i 1
  • while (i lt 1000)
  • ...
  • i
  • After
  • int i 1
  • while ((i lt 1000) (i 1000 0))
  • ...
  • i

31
Experiment
  • I evaluated three decompliers
  • Mocha
  • JODE
  • Jad
  • and three obfuscators
  • ProGuard
  • JODE
  • JavaGuard

32
The Process
  • Chose 3 programs in Java
  • Compiled the programs creating .class files for
    all
  • Then using the three decompilers mentioned above
    on the .class files and decompiled the 10
    programs.
  • The resulted source code was relatively easy to
    build and read

33
The Process (2)
  • 4. Applied Obfuscation
  • 5. applied decompilers
  • This time the result was much harder to
    understand and in some cases not possible

34
The Tools
  • The Mocha easier to use, it simply produces
    Mocha.java code.
  • The JAD was the hardest one to work with
  • JODE similar to JAD in terms of complexity

35
Obfuscators
  • All the three obfuscators apply Layout
    Obfuscation
  • Data obfuscation were different in the three
    tools
  • Other types of obfuscation makes the program very
    hard to understand but not impossible.

36
Benchmarking
37
Conclusion
  • Code obfuscation while not providing absolute
    security
  • is portable
  • does not require specialized hardware
  • is transparent to the Java bytecode verifier
  • it does impose an execution time-space penalty on
    the program being protected.

38
  • Questions?

39
References
  • http//www.w3.org/Conferences/WWW4/Papers/197/40.h
    tml
  • http//www.developer.com/open/article.php/779831
  • http//www.cs.arizona.edu/collberg/Research/Stude
    nts/DouglasLow/obfuscation.html
Write a Comment
User Comments (0)
About PowerShow.com