Bringing java's wild native world under control

The ubiquitously-installed Java Runtime Environment (JRE) provides a complex, flexible set of mechanisms that support the execution of untrusted code inside a secure sandbox. However, many recent exploits have successfully escaped the sandbox, allowing attackers to infect numerous Java hosts. We hypothesize that the Java security model affords developers more flexibility than they need or use in practice, and thus its complexity compromises security without improving practical functionality. We describe an empirical study of the ways benign open-source Java applications use and interact with the Java security manager. We found that developers regularly misunderstand or misuse Java security mechanisms, that benign programs do not use all of the vast flexibility afforded by the Java security model, and that there are clear differences between the ways benign and exploit programs interact with the security manager. We validate these results by deriving two restrictions on application behavior that restrict (1) security manager modifications and (2) privilege escalation. We demonstrate that enforcing these rules at runtime stop a representative proportion of modern Java 7 exploits without breaking backwards compatibility with benign applications. These practical rules should be enforced in the JRE to fortify the Java sandbox.

Javana is a tool for creating customized Java program analysis tools. It comes with an easy-to-use instrumentation framework that enables programmers to develop profiling tools that crosscut the Java application, the Java Virtual Machine (JVM) and the native execution layers. The goal of this poster is to demonstrate the power of Javana, using object lifetime computation as an example.Object lifetime has proven to be useful for analyzing and optimizing the behavior of Java applications. Computing object lifetime is conceptually simple, however, in practice it is often challenging. The JVM needs to be adjusted in numerous ways in order to track all possible accesses to all objects, including accesses that occur through the Java Native Interface (JNI), the standard class libraries, and the JVM implementation itself. Capturing all object accesses through manual instrumentation requires an in-depth understanding of the JVM and its libraries. We show that using Javana is both easier and more accurate than manual instrumentation.

This article aims to explore JNI features and to discover fundamental operations of the Java programming language, such as arrays, objects, classes, threads and exception handling, and to illustrate these by using various algorithms and code samples. The authors also investigate the JNI Invocation API that allows native applications to interact with the Java Virtual Machine (JVM). They focus on attaching native threads to a running JVM and on leveraging existing native code using one-to-one mapping and shared stubs.

Current developments show that tomorrow's information systems and applications will no longer be based on monolithic architectures that encompass all the functionality. Rather, the emerging need for distribution and quick adaptation to new requirements stemming from, e.g., virtual enterprises, demands distributed systems that can be extended dynamically to compose new services from existing software components. However, usage of mobile code introduces specific security concerns which a security system must be aware of. We present a comprehensive security architecture for extensible, distributed systems using the example of an Internet query processing service which can be extended by user-defined operators. Before an operator is actually used in queries for the first time, our OperatorCheck server validates its semantics and analyzes its quality. This is done semi-automatically using an oracle-based approach to compare a formal specification of an operator against its implementation. Further security measures are integrated into the query processing engine: during plan distribution secure communication channels are established, authentication and authorization are performed, and overload situations are avoided by admission control. During plan execution operators are guarded using Java's security model to prevent unauthorized resource access and leakage of data. The resource consumption of operators is monitored and limited with reasonable supplementary costs to avoid resource monopolization. We show that the presented security system is capable of executing arbitrary operators without risks for the executing host and the privacy and integrity of data. In the paper we will concentrate on the OperatorCheck server, as this server can itself be viewed as an e-service that can be used by developers and independent associations.

This paper unveils two facts that are tightly linked: firstly, Internet users require increasingly effective security policies, since there are plenty of scenarios where the introduction of security elements is highly recommended (e.g. integrity and confidentiality requirements in the everyday use of interpersonal communications by e-mail). Secondly, checking the suitability and performance of an object-oriented programming language which considers itself platform-independent (as Java from Sun Microsystems claims to be) as the essential tool to implement that level of security is a great challenge. The unsophisticated Java application that is introduced attempts to be the meeting point of these two new technology trends, user security and platform independence. It constitutes an example of a secure application in Java that deploys ciphering and signing features within the Java security model.

High-level languages such as Java increase both productivity and portability with productive language features such as managed runtime, type safety, and precise exception semantics. Additionally, Java 8 provides parallel stream APIs with lambda expressions to facilitate parallel programming for mainstream users of multi-core CPUs and many-core GPUs. These high-level APIs avoid the complexity of writing natively running parallel programs with OpenMP and CUDA/OpenCL through Java Native Interface (JNI). The adoption of such high-level programming models offers opportunities for enabling compilers to perform parallel-aware optimizations and code generation.While many prior approaches have the ability to generate parallel code for both multi-core CPUs and many-core GPUs from Java and other high-level languages, selection of the preferred computing resource between CPUs and GPUs for individual kernels remains one of the most important challenges since a variety of factors affecting performance such as datasets and feature of programs need to be taken into account.This paper explores the possibility of using machine learning to address this challenge. The key idea is to enable a Java runtime to select a preferable hardware device with performance heuristics constructed by supervised machine-learning techniques. For this purpose, if our JIT compiler detects a parallel stream API, 1) our compiler records features of its computation such as the parallel loop range and the number of instructions and 2) our Java runtime generates these features for constructing training data. For the results reported in this paper, we constructed a prediction model with support vector machines (SVMs) after obtaining 291 samples by running 11 applications with different data sets and optimization levels. Our Java runtime then uses the SVMs to make predictions for unseen programs.Our experimental results on an IBM POWER8 platform with NVIDIA Tesla GPUs show that our prediction model predicts a faster configuration with up to 99.0% accuracy with 5-fold cross validation. Based on these results, we conclude that supervised machine-learning is a promising approach for building performance heuristics for mapping Java applications onto accelerators.

Android apps include third-party native libraries to increase performance and to reuse functionality. Native code is directly executed from apps through the Java Native Interface or the Android Native Development Kit. Android developers add precompiled native libraries to their projects, enabling their use. Unfortunately, developers often struggle or simply neglect to update these libraries in a timely manner. This results in the continuous use of outdated native libraries with unpatched security vulnerabilities years after patches became available. To further understand such phenomena, we study the security updates in native libraries in the most popular 200 free apps on Google Play from Sept. 2013 to May 2020. A core difficulty we face in this study is the identification of libraries and their versions. Developers often rename or modify libraries, making their identification challenging. We create an approach called LibRARIAN (LibRAry veRsion IdentificAtioN) that accurately identifies native libraries and their versions as found in Android apps based on our novel similarity metric bin2sim. LibRARIAN leverages different features extracted from libraries based on their metadata and identifying strings in read-only sections. We discovered 53/200 popular apps (26.5%) with vulnerable versions with known CVEs between Sept. 2013 and May 2020, with 14 of those apps remaining vulnerable. We find that app developers took, on average, 528.71 ±40.20 days to apply security patches, while library developers release a security patch after 54.59 ± 8.12 days---a 10 times slower rate of update.

The paper presents a practical approach to construction of a software tool, which will be suitable for deployment of Java components in distributed and heterogeneous testbeds. Requirements of such a system are identified, and a suitable architecture, which is scalable and allows the installation and starting Java applications on chosen computational nodes, is proposed. The modular architecture of the constructed system is based on JMX (Java management extensions), which require packaging each Java component as an MBean and providing a deployment descriptor for it in the form of an XML MLet file. Such an approach can be applied to building a lightweight framework for Java applications and services using only one Java virtual machine per computational node, where each component is installed and started in the same JVM, thus limiting valuable resource consumption. This approach cannot be useful for end-user applications without additional services allowing it to control and manage the deployed modules. Some of them include standard JMX services, such as the MLet service (for dynamic loading), while some have to be developed specifically for the purpose of operating in distributed testbeds. A detailed discussion of the system requirements, architecture of the implemented system called JIMS, built on the top of JMX core components are presented in this paper.

Just-in-time (JIT) compilation during program execution and ahead-of-time (AOT) compilation during software installation are alternate techniques used by managed language virtual machines (VM) to generate optimized native code while simultaneously achieving binary code portability and high execution performance. Profile data collected by JIT compilers at run-time can enable profile-guided optimizations (PGO) to customize the generated native code to different program inputs. AOT compilation removes the speed and energy overhead of online profile collection and dynamic compilation, but may not be able to achieve the quality and performance of customized native code. The goal of this work is to investigate and quantify the implications of the AOT compilation model on the quality of the generated native code for current VMs. First, we quantify the quality of native code generated by the two compilation models for a state-of-the-art (HotSpot) Java VM. Second, we determine how the amount of profile data collected affects the quality of generated code. Third, we develop a mechanism to determine the accuracy or similarity for different profile data for a given program run, and investigate how the accuracy of profile data affects its ability to effectively guide PGOs. Finally, we categorize the profile data types in our VM and explore the contribution of each such category to performance.

The Java Native Interface (JNI) comes with the standard Java Development Kit (JDK) from Sun Microsystems. It permits Java programmers to integrate native code (currently C and C++) into their Java applications. This article will focus on how to make use of the JNI and will provide a few examples illustrating the usefulness of this feature. Although a native method system was included with the JDK 1.0 release, this article is concerned with the JDK 1.1 JNI which has several new features, and is much cleaner than the previous release. Also, the examples given will be specific to JDK 1.1 installed on the Solaris Operating System.

While the Java Virtual Machine (JVM) plays a vital role in ensuring correct executions of Java applications, testing JVMs via generating and running class files on them can be rather challenging. The existing techniques, e.g., ClassFuzz and Classming, attempt to leverage the power of fuzzing and differential testing to cope with JVM intricacies by exposing discrepant execution results among different JVMs, i.e., inter-JVM discrepancies, for testing analytics. However, their adopted fuzzers are insufficiently guided since they include no well-designed seed and mutator scheduling mechanisms, leading to inefficient differential testing. To address such issues, in this paper, we propose SJFuzz, the first JVM fuzzing framework with seed and mutator scheduling mechanisms for automated JVM differential testing. Overall, SJFuzz aims to mutate class files via control flow mutators to facilitate the exposure of inter-JVM discrepancies. To this end, SJFuzz schedules seeds (class files) for mutations based on the discrepancy and diversity guidance. SJFuzz also schedules mutators for diversifying class file generation. To evaluate SJFuzz, we conduct an extensive study on multiple representative real-world JVMs, and the experimental results show that SJFuzz significantly outperforms the state-of-the-art mutation-based and generation-based JVM fuzzers in terms of the inter-JVM discrepancy exposure and the class file diversity. Moreover, SJFuzz successfully reported 46 potential JVM issues, and 20 of them have been confirmed as bugs and 16 have been fixed by the JVM developers.

Managed language runtimes such as the Java Virtual Machine (JVM) provide adequate performance for a wide range of applications, but at the same time, they lack much of the low-level control that performance-minded programmers appreciate in languages like <pre>C/C++</pre>. One important example is the intrinsics interface that exposes instructions of SIMD (Single Instruction Multiple Data) vector ISAs (Instruction Set Architectures). In this paper we present an automatic approach for including native intrinsics in the runtime of a managed language. Our implementation consists of two parts. First, for each vector ISA, we automatically generate the intrinsics API from the vendor-provided XML specification. Second, we employ a metaprogramming approach that enables programmers to generate and load native code at runtime. In this setting, programmers can use the entire high-level language as a kind of macro system to define new high-level vector APIs with zero overhead. As an example use case we show a variable precision API. We provide an end-to-end implementation of our approach in the HotSpot VM that supports all 5912 Intel SIMD intrinsics from <pre>MMX</pre> to <pre>AVX-512</pre>. Our benchmarks demonstrate that this combination of SIMD and metaprogramming enables developers to write high-performance, vectorized code on an unmodified JVM that outperforms the auto-vectorizing HotSpot just-in-time (JIT) compiler and provides tight integration between vectorized native code and the managed JVM ecosystem.

The R language is widely used for data analysis. However, it does not allow for complex object-oriented implementation and it tends to be slower than other languages such as Java, C and C++. Consequently, it can be more computationally efficient to run native Java code in R. To do this, there exist at least two approaches. One is based on the Java Native Interface (JNI) and it has been successfully implemented in the rJava package. An alternative approach consists of running a local server in Java and linking it to an R environment through a socket connection. This alternative approach has been implemented in an R package called J4R. This article shows how this approach makes it possible to simplify the calls to Java methods and to integrate the R vectorization. The downside is a loss of performance. However, if the vectorization is used in conjunction with multithreading, this loss of performance can be compensated for.

Memory footprint is considered as an important design issue for embedded systems. Sharing dynamically compiled code among virtual machines can reduce memory footprint and recompilation overhead. On the other hand, sharing writable native code may cause security problems, due to support of native function call such as Java Native Interface (JNI). We propose a native-code sharing mechanism that ensures the security for Dalvik virtual machine (VM) on the Android platform. Dynamically generated code is saved in a file and is shared with memory mapping when other VMs need the same code. Protection is granted by controlling of file writing permissions. To improve the security, we implement a daemon process, named Query Agent, to control all accesses to the native code and maintain all the information of traces, which are the units of the compilation in the Dalvik VM. We implement our code sharing mechanism on Android version 2.1 system, and experiment on an arm-based system. We get 45% code-cache size reduction and 9% performance improvement from eliminating recompilation overhead.

Java is growing in appropriateness and usability for high performance computing. With this increasing adoption, issues relating to combining Java with existing codes in other languages become more important. The Java Native Interface (JNI) API is portable but too inconvenient to be used directly owing to its low-level API. This paper presents Janet — a highly expressive Java language extension and preprocessing tool that enables convenient integration of native code with Java programs. The Janet methodology overcomes some of the limitations of JNI and generates Java programs that execute with little or no degradation despite the flexibility and generality of the interface.