Results 1 - 10
of
16
Robusta: Taming the Native Beast of the JVM
"... Java applications often need to incorporate native-code components for efficiency and for reusing legacy code. However, it is well known that the use of native code defeats Java’s security model. We describe the design and implementation of Robusta, a complete framework that provides safety and secu ..."
Abstract
-
Cited by 19 (7 self)
- Add to MetaCart
(Show Context)
Java applications often need to incorporate native-code components for efficiency and for reusing legacy code. However, it is well known that the use of native code defeats Java’s security model. We describe the design and implementation of Robusta, a complete framework that provides safety and security to native code in Java applications. Starting from software-based fault isolation (SFI), Robusta isolates native code into a sandbox where dynamic linking/loading of libraries is supported and unsafe system modification and confidentiality violations are prevented. It also mediates native system calls according to a security policy by connecting to Java’s security manager. Our prototype implementation of Robusta is based on Native Client and OpenJDK. Experiments in this prototype demonstrate Robusta is effective and efficient, with modest runtime overhead on a set of JNI benchmark programs. Robusta can be used to sandbox native libraries used in Java’s system classes to prevent attackers from exploiting bugs in the libraries. It can also enable trustworthy execution of mobile Java programs with native libraries. The design of Robusta should also be applicable when other type-safe languages (e.g., C#, Python) want to ensure safe interoperation with native libraries.
Bringing Java’s Wild Native World under Control
, 2013
"... For performance and for incorporating legacy libraries, many Java applications contain native-code com-ponents written in unsafe languages such as C and C++. Native-code components interoperate with Java components through the Java Native Interface (JNI). As native code is not regulated by Java’s se ..."
Abstract
-
Cited by 5 (0 self)
- Add to MetaCart
For performance and for incorporating legacy libraries, many Java applications contain native-code com-ponents written in unsafe languages such as C and C++. Native-code components interoperate with Java components through the Java Native Interface (JNI). As native code is not regulated by Java’s security model, it poses serious security threats to the managed Java world. We introduce a security framework that extends Java’s security model and brings native code under control. Leveraging software-based fault isolation, the framework puts native code in a separate sandbox and allows the interaction between the native world and the Java world only through a carefully designed pathway. Two different implementa-tions were built. In one implementation, the security framework is integrated into a Java Virtual Machine (JVM). In the second implementation, the framework is built outside of the JVM and takes advantage of JVM-independent interfaces. The second implementation provides JVM portability, at the expense of some performance degradation. Evaluation of our framework demonstrates that it incurs modest runtime overhead while significantly enhancing the security of Java applications.
JVM-Portable Sandboxing of Java’s Native Libraries
"... Abstract. Although Java provides strong support for safety and security, native libraries used in a Java application can open security holes. Previous work, Robusta, puts native libraries in a sandbox to protect the integrity and security of Java. However, Robusta’s implementation modifies the inter ..."
Abstract
-
Cited by 4 (2 self)
- Add to MetaCart
(Show Context)
Abstract. Although Java provides strong support for safety and security, native libraries used in a Java application can open security holes. Previous work, Robusta, puts native libraries in a sandbox to protect the integrity and security of Java. However, Robusta’s implementation modifies the internals of OpenJDK, a particular implementation of a Java Virtual Machine (JVM). As such, it is not portable to other JVM implementations. This paper shows how to make the idea of sandboxing native libraries JVM-portable. We present a two-layer approach for sandboxing without modifying the internals of a JVM. We also discuss our experience of sandboxing Java’s core native libraries. Experiments show that our approach of JVM-portable sandboxing incurs modest performance overhead on SPECjvm 2008 benchmark programs. 1
JATO: Native Code Atomicity for Java
"... Abstract. Atomicity enforcement in a multi-threaded application can be critical to the application’s safety. In this paper, we take the challenge of enforcing atomicity in a multilingual application, which is developed in multiple programming languages. Specifically, we describe the design and imple ..."
Abstract
-
Cited by 3 (3 self)
- Add to MetaCart
(Show Context)
Abstract. Atomicity enforcement in a multi-threaded application can be critical to the application’s safety. In this paper, we take the challenge of enforcing atomicity in a multilingual application, which is developed in multiple programming languages. Specifically, we describe the design and implementation of JATO, which enforces the atomicity of a native method when a Java application invokes the native method through the Java Native Interface (JNI). JATO relies on a constraint-based system, which generates constraints from both Java and native code based on how Java objects are accessed by threads. Constraints are then solved to infer a set of Java objects that need to be locked in native methods to enforce the atomicity of the native method invocation. We also propose a number of optimizations that soundly improve the performance. Evaluation through JATO’s prototype implementation demonstrates it enforces native-method atomicity with reasonable run-time overhead. 1
JNI Light: An Operational Model for the Core JNI
"... Through foreign function interfaces (FFIs), software components in different programming languages interact with each other in the same address space. Recent years have witnessed a number of systems that analyze FFIs for safety and reliability. However, lack of formal specifications of FFIs hamper ..."
Abstract
-
Cited by 2 (1 self)
- Add to MetaCart
(Show Context)
Through foreign function interfaces (FFIs), software components in different programming languages interact with each other in the same address space. Recent years have witnessed a number of systems that analyze FFIs for safety and reliability. However, lack of formal specifications of FFIs hampers progress in this endeavor. We present a formal operational model, JNI Light (JNIL), for a subset of a widely used FFI—the Java Native Interface (JNI). JNIL focuses on the core issues when a high-level garbage-collected language interacts with a low-level language. It proposes abstractions for handling a shared heap, crosslanguage method calls, cross-language exception handling, and garbage collection. JNIL can directly serve as a formal basis for JNI tools and systems. The abstractions in JNIL are also useful when modeling other FFIs, such as the Python/C interface and the OCaml/C interface.
Finding Reference-Counting Errors in Python/C Programs with Affine Analysis
"... Abstract. Python is a popular programming language that uses refer-ence counting to manage heap objects. Python also has a Foreign Func-tion Interface (FFI) that allows Python extension modules to be written in native code such as C and C++. Native code, however, is outside Python’s system of memory ..."
Abstract
-
Cited by 2 (0 self)
- Add to MetaCart
(Show Context)
Abstract. Python is a popular programming language that uses refer-ence counting to manage heap objects. Python also has a Foreign Func-tion Interface (FFI) that allows Python extension modules to be written in native code such as C and C++. Native code, however, is outside Python’s system of memory management; therefore extension program-mers are responsible for making sure these objects are reference counted correctly. This is an error prone process when code becomes complex. In this paper, we propose Pungi, a system that statically checks whether Python objects ’ reference counts are adjusted correctly in Python/C in-terface code. Pungi transforms Python/C interface code into affine pro-grams with respect to our proposed abstractions of reference counts. Our system performs static analysis on transformed affine programs and re-ports possible reference counting errors. Our prototype implementation found over 150 errors in a set of Python/C programs.
NativeGuard: Protecting Android Applications from Third-Party Native Libraries
"... Android applications often include third-party libraries writ-ten in native code. However, current native components are not well managed by Android’s security architecture. We present NativeGuard, a security framework that isolates native libraries from other components in Android applica-tions. Le ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
(Show Context)
Android applications often include third-party libraries writ-ten in native code. However, current native components are not well managed by Android’s security architecture. We present NativeGuard, a security framework that isolates native libraries from other components in Android applica-tions. Leveraging the process-based protection in Android, NativeGuard isolates native libraries of an Android applica-tion into a second application where unnecessary privileges are eliminated. NativeGuard requires neither modifications to Android nor access to the source code of an application. It addresses multiple technical issues to support various in-terfaces that Android provides to the native world. Exper-imental results demonstrate that our framework works well with a set of real-world applications, and incurs only modest overhead on benchmark programs.
Improving Device Driver Reliability through Decoupled Dynamic Binary Analyses
, 2013
"... Device drivers are Operating Systems (OS) extensions that enable the use of I/O devices in computing systems. However, studies have identified drivers as an Achilles ’ heel of system reliability, their high fault rate accounting for a significant portion of system failures. Consequently, significant ..."
Abstract
- Add to MetaCart
(Show Context)
Device drivers are Operating Systems (OS) extensions that enable the use of I/O devices in computing systems. However, studies have identified drivers as an Achilles ’ heel of system reliability, their high fault rate accounting for a significant portion of system failures. Consequently, significant effort has been directed towards improving system robustness by protecting system components (e.g., OS kernel, I/O devices, etc.) from the harmful effects of driver faults. In contrast to prior techniques which focused on preventing unsafe driver interactions (e.g., with the OS kernel), my thesis is that checking a driver’s execution for correctness violations results in the detection and mitigation of more faults. To validate this thesis, I present Guardrail, a flexible and powerful framework that enables instruction-grained dynamic analysis (e.g., data race detection) of unmodified kernel-mode driver binaries to safeguard I/O operations and devices from driver faults. Guardrail decouples the analysis tool from driver execution to improve performance, and runs it in user-space to simplify the deployment of new tools. Moreover, Guardrail leverages virtualization to be transparent to both the driver and device, and enable support for arbitrary driver/device combinations. To demonstrate Guardrail’s generality, I implemented three novel dynamic checking tools
Generating Sound and Effective Memory Debuggers
"... We present a new approach for constructing debuggers based on declarative specification of bug conditions and root causes, and automatic generation of debugger code. We illustrate our approach on several classes of bugs, memory or otherwise. For each bug class, bug conditions and their root cause ar ..."
Abstract
- Add to MetaCart
(Show Context)
We present a new approach for constructing debuggers based on declarative specification of bug conditions and root causes, and automatic generation of debugger code. We illustrate our approach on several classes of bugs, memory or otherwise. For each bug class, bug conditions and their root cause are specified declaratively, in First-order logic, using 1 to 4 predicates. We employ a low-level operational semantics and abstract traces to permit concise bug specification and prove soundness. To facilitate locating bugs, we introduce a new concept of value propagation chains that reduce programmer burden by narrowing the fault to a handful of executed instructions (1 to 16 in our experiments). We employ automatic translation to generate the debugger implementation, which runs on top of the Pin infrastructure. Experiments with using our system on 7 versions of 4 real-world programs show that our approach is expressive, effective at finding bugs and their causes, and efficient. We believe that, using our approach, other kinds of declarativelyspecified, provably-correct, auto-generated debuggers can be constructed with little effort.
