1 / 31

Quarantine: A Framework to Mitigate Memory Errors in JNI Applications

Quarantine: A Framework to Mitigate Memory Errors in JNI Applications. Du Li ， Witawas Srisa-an University of Nebraska-Lincoln. JNI(J ava Native Interface ). I ntegrating legacy code, making use of existing libraries, components. Developing applications in multiple languages

zelda
Download Presentation

Quarantine: A Framework to Mitigate Memory Errors in JNI Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Quarantine: A Framework to Mitigate Memory Errors in JNI Applications Du Li，Witawas Srisa-an University of Nebraska-Lincoln

  2. JNI(Java Native Interface) • Integrating legacy code, making use of existing libraries, components. • Developing applications in multiple languages • Java UI + C backend Java Code JNI Native Code Application

  3. When Java meets C, C++ … • Issues in JNI • Type mismatching • Access mechanism mismatching • Memory leaking • Memory safety • …

  4. Example of JNI App C Java Get() Put() … Table Interface JNI Hashtable

  5. Example of JNI App C Java 32-bit int addr Get() Put() … Table Interface JNI Hashtable

  6. Example of JNI App C Java 64-bit int addr Get() Put() … Table Interface JNI Hashtable

  7. Example of JNI App C Java 64-bit int addr Get() Put() … Table Interface JNI Hashtable

  8. And Even Worse …

  9. Motivation • JNI can cause nasty memory bugs • Lack ofmechanism to address or mitigate memory faults in JNI applications

  10. Empirical Study on JNI Bugs • 126 JNI related bugs are identified in OpenJDK 1.6 • 59out of 126 bugs are security critical • “A time bomb” An Empirical Security Study of the Native Code in the JDK. G. Tan and J. Croft. In USENIX Security 2008

  11. Bug Patterns • C pointers as Java integers • Memory Management Flaws • Buffer Overflows • Mishandling JNI exceptions • Race conditions in file accesses • Insufficient error checking An Empirical Security Study of the Native Code in the JDK. G. Tan and J. Croft. In USENIX Security 2008

  12. Bug Patterns • C pointers as Java integers • Memory Management Flaws • Buffer Overflows • Mishandling JNI exceptions • Race conditions in file accesses • Insufficient error checking Related to memory faults Caused by mismatching of heap management mechanism An Empirical Security Study of the Native Code in the JDK. G. Tan and J. Croft. In USENIX Security 2008

  13. C pointers as Java Integers • As we showed in JNI hashtable example • Store C pointers as Java integers • Pass back to C and cast to pointers when needed • Native code will update the Java Interger • It can corrupt Java heap by writing arbitrary data

  14. Memory Management Flaws • Automatic memory management in Java • Manual memory management for Java heap in JNI • e.g. Get/ReleaseIntArrayElements, Get/ReleaseStringUTFChars …

  15. Buffer Overflow • No type safety in some native code • C is not type safe language • No type checking in JNI read/write • e.g. native code can write a float value to a byte type variable in Java

  16. Challenge • Existing techniques(DieHard, LeakingChaser) can detect and mitigate the above issues • But the overhead is too high to feasibly apply such techniques to the whole heap Emery D. Berger and Benjamin G. Zorn. 2006. DieHard: probabilistic memory safety for unsafe languages (PLDI '06) Xu, Bond, Qin, Rountev, LeakChaser: Helping Programmers Narrow Down Causes of Memory Leaks (PLDI'11)

  17. Unsafe objects are few Unsafe objects: objects accessible by native code Less than 1% objects are unsafe.

  18. Status × × × × × ×

  19. Goal × × × × × ×

  20. Approach • Quarantine • Identify unsafe objects • Segment identified unsafe objects • Apply treatment to segmented objects

  21. Identify Unsafe Objects • Instrument “native” methods to find • Objects created by native code • Objects created by Java code and exposed to native code

  22. Segmentation All unsafe objects will be allocated in or copied to JNI space

  23. Implementation • Based on Jikes RVM 3.1.0 • Build object migration mechanism • Change object header to record forwarding address • Leverage the read/write barriers

  24. Runtime Overhead

  25. Breaking Down Overhead

  26. Experiment: Applying Padding • Inspired by a mechanism in DieHard • Creating object x-times larger than the actual size • Do this for every object • Do this for only quarantined objects a b a b

  27. Experiment: Applying Padding Performance of RVM with Quarantine with 2x Padding

  28. Experiment: Applying Padding GC Invocations GC Performance of RVM with Quarantine with 2x Padding

  29. Conclusion • Develop aframework • to identify JNI accessible objects • to segment JNI accessible objects • to facilitate applying protection technique to mitigate JNI related bugs

  30. Acknowledgments • Partial support for this work is provided by NSF (CNS-0720757) and AFOSR (FA9550-09-1- 0129) • We thank Laurence Hellyer for making the primitive barrier code available and spending time to answer our questions

  31. Question & Answer & Discussion

More Related