Safe Java Native Interface∗Gang Tan†‡§Andrew W. Appel‡Srimat Chakradhar§Anand Raghunathan§Srivaths Ravi§Daniel Wang‡†Department of Computer Science, Boston College‡Department of Computer Science, Princeton University§NEC Laboratories AmericaAbstractType safety is a promising approach to enhancing soft-ware security. Programs written in type-safe programminglanguages such as Java are type-safe by construction. How-ever, in practice, many complex applications are heteroge-neous, i.e., they contain components written in different lan-guages. The Java Native Interface (JNI) allows type-safeJava code to interact with unsafe C code. When a type-safelanguage interacts with an unsafe language in the same ad-dress space, in general, the overall application becomes un-safe.In this work, we propose a framework called Safe JavaNative Interface (SafeJNI) that ensures type safety of het-erogeneous programs that contain Java and C components.We identify the loopholes of using JNI that would permitC code to bypass the type safety of Java. The proposedSafeJNI system fixes these loopholes and guarantees typesafety when native C methods are called. The overall ap-proach consists of (i) retro-fitting the native C methods tomake them safe, and (ii) developing an enhanced systemthat captures additional invariants that must be satisfied toguarantee safe interoperation. The SafeJNI framework isimplemented through a combination of static and dynamicchecks on the C code.We have measured our system’s effectiveness and per-formance on a set of benchmarks. During our experimentson the Zlib open source compression library, our systemidentified one vulnerability in the glue code between Zliband Java. This vulnerability could be exploited to crash alarge number of commercially deployed Java Virtual Ma-chines (JVMs). The performance impact of SafeJNI on Zlib,while considerable, is less than reimplementing the C code∗To appear in IEEE International Symposium on Secure Software Engi-neering, March 2006. This research was supported in part by ARDA awardNBCHC030106. This information does not necessarily reflect the opinionor policy of the federal government and no official endorsement should beinferred.‡Daniel Wang is currently at Microsoft Corporation.in Java.1 IntroductionLarge software systems often contain components devel-oped using different programming languages. This may oc-cur due to a variety of factors, including ease of develop-ment and maintenance, reuse of legacy code, and efficiency.For example, a browser for an embedded device such asa cell phone may have a user interface written in Java, andmodules written in C that implement plugins, media codecs,and so on.For software components in different languages to inter-operate, there must be a standard interface between them.One way to achieve this is through a foreign function inter-face (FFI). Most modern programming languages provide aforeign function interface [14, 3, 13, 6, 7]. For example, theJava Native Interface (JNI) [14] enables Java code runninginside a Java Virtual Machine (JVM) to interoperate withcomponents that are written in C.Unsafe and insecure interoperation. An FFI usually ad-dresses discrepancies between the two languages on issuessuch as the representation of data, memory management,calling conventions. However, what most interfaces fail toaddress is the discrepancy between the safety guaranteesof different languages. When a component written in asafe language directly interacts with a component writtenin an unsafe language, the whole application becomes un-safe. This is certainly the case when Java code interoperateswith C code through the JNI interface. Even rich systemslike Microsoft’s .NET CLR [10] have this problem. The.NET CLR distinguishes between “managed” and “unman-aged” code. Linking unmanaged code with managed codenullifies the safety guarantees of the managed code.Approaches to safe interoperation. Systems like COM[16], SOAP [19], and CORBA [9] are based on RemoteProcedure Calls (RPC); they achieve safe interoperation byplacing components in different address spaces, thus isolat-ing the unsafe components from the safe components. How-ever, they still do not guarantee the safety of the individualcomponents. Moreover, these approaches come with a sig-nificant overhead, in the form of context switches and inter-component communication. These costs limit the practicalapplicability of these approaches in many scenarios. Weare interested in FFI-based approaches since they are morelightweight.Another approach is to manually reimplement everycomponent in safe languages. For instance, the JCraft web-site [1] provides reimplementations in pure Java of manyprograms originally written in C, including the X Windowserver, Zlib compression libraries, etc. This approach re-quires substantial programming effort, and also negativelyimpacts execution speed.Towards safe interoperation through FFIs. Our goal is tohave an FFI-based approach that achieves safe interopera-tion between different languages. In particular, we target theJNI interface, since Java and C are two popular languages.Ideally, we would like the calling of C code in Java to beas safe as the calling of Java code in Java. To achieve this,we have examined how C code, through JNI, may exploitloopholes to violate Java’s type safety.The most obvious problem is that C code is inherentlyunsafe and may read/write any memory address. Fortu-nately, there are systems such as CCured [15] and Cy-clone [12] that provide safety guarantees for legacy C codethrough a combination of static and dynamic checks.However, just providing internal safety for the C code isnot sufficient to guarantee safe interoperation between Javaand C. The JNI interface, if not used properly, has manyloopholes. A simple example is that C code can pass ob-jects of the wrong classes to Java and thus violate Java’stype safety. In summary, ensuring the safety of the individ-ual components separately is not sufficient to guarantee thesafety of the entire program.The contribution of this paper is the SafeJNI system,which can ensure type safety when Java programs interactwith C programs through JNI. We decompose the overallproblem into two parts: ensuring that the C code is safe initself, and ensuring that the C code does not violate the safeinteroperation rules of JNI. Our current implementation ofSafeJNI leverages CCured [15] to provide internal safetyfor the C code. In addition,