CHERI JNI: Sinking the Java security model into the C David Chisnall - PowerPoint PPT Presentation

CHERI JNI: Sinking the Java security model into the C David Chisnall , Brooks Davis, Khilan Gudka, David Brazdil, Alexandre Joannou, Jonathan Woodruff, A. Theodore Markettos, J. Edward Maste, Robert Norton, Stacey Son, Michael Roe, Simon W. Moore, Peter G. Neumann, Ben Laurie, Robert N. M. Watson Approved for public release; distribution is unlimited. This research is sponsored by the Defense Advanced Research Projects Agency (DARPA) and the Air Force Research Laboratory (AFRL), under contract FA8750-10-C-0237. The views, opinions, and/or findings contained in this article/presentation are those of the author(s)/presenter(s) and should not be interpreted as representing the official views or policies of the Department of Defense or the U.S. Government.

The Java abstract machine Java VM Native Code Type safe Fast JNI Garbage collected Full control over memory Data hiding Basically full of evil Security policy enforcement 2

The Java concrete machine Native Code Java VM Type safe JNI Garbage collected Data hiding Security policy enforcement Fast Full control over memory Basically full of evil 3

JNI is insecure by design The JNI does not check for programming errors such as passing in NULL pointers or illegal argument types. Most C library functions do not guard against programming errors…The programmer must not pass illegal pointers or arguments of the wrong type to JNI functions. Doing so could result in arbitrary consequences, including a corrupted system state or VM crash. 4

BRIEF CHERI PRIMER 5

Hardware memory safety 1-bit tag v objtype (24bits) permissions (31 bits) s capability 256-bit length (64 bits) pointer (64 bits) offset (64 bits) base (64 bits) Virtual address space Compressed representation provides the same abstract model in 128 bits. 6

Sealing gives opaque pointers Trusted code Untrusted code Trusted code Data Capability Sealed Seal Capability Sealing Data Unseal Capability Capability Trap! Unseal Other data 7

CHERI AND THE JNI 8

CHERI JNI Native Code Java VM Fast Full control over local memory Memory-safe access to Java buffers JNI Controlled access to Java objects Evil stays in the box Type safe Garbage collected Data hiding Native Code Security policy enforcement Declarative policy for JNI sandboxed native code. Native Code JNI 9

Sandbox scopes Fast Global Object Method Secure Easy 10

Direct buffer access Java NIO class intended to provide C code with direct class Foo { access to JVM-owned @Sandbox(...) memory native long process(ByteBuffer buf) } JNIEXPORT void JNICALL Java_Foo_process (JNIEnv *env, jobject this, jobject buf) { char *b = (*env)->GetDirectBufferAddress(env, buf); someNativeLibraryThing(buf); } 11

Direct buffer access Bounds-checked access to JVM-owned buffer and class Foo { nothing else. @Sandbox(...) No store permission if the native long process(ByteBuffer buf) ByteBuffer is read only. } JNIEXPORT void JNICALL Java_Foo_process (JNIEnv *env, jobject this, jobject buf) { char *b = (*env)->GetDirectBufferAddress(env, buf); someNativeLibraryThing(buf); } 12

Avoiding type confusion Exploitable vulnerability in existing state of the art SFI-based technique. JVM does: CHERI JNI checks f and r are *(r + (f->offset)) = 42; sealed with the correct type, No type checking of f . errors if not. // Get the field ID for integer field x jfieldID f = (*env)->GetFieldID(env, cls, "x", "I"); // Set that field to 42 (*env)->SetIntField(env, r, f, 42); 13

CHERI vs prior sandboxing work Mechanism JITs Stack Many Direct Unwinders Sandboxes buffers CHERI ✔ ✔ ✔ ✔ SFI-based X X X X Process-based X X ✔ ✔ 14

Garbage collection extends to C • All Java references in C code are sealed capabilities • All pointers to Java arrays or direct buffers are unsealed (but bounded) capabilities • All capabilities are protected by a tag bit • The garbage collector can find them in memory 15

Conclusion • CHERI allows the Java security model to be extended all of the way through native code • Native code cannot violate the invariants of the JVM • Performance is comparable with conventional JNI implementations 16