Tag Archives: Native

Student thesis project: Classification of native methods of the JCL using an analysis of their implementation

The Java Class Library (JCL) – with Java being one of the majorly adopted programming languages – is heavily used and an implicitly trusted library on which many mission critical applications are based. In order to prevent abuse, Java has a sophisticated security model to ensure the isolation of protected areas inside a program. However, attackers have found and continue to find several ways to disable the security model thus rendering it useless.

One way of effectively evading the Java security model is to perform operations in native code. Since attackers cannot easily introduce new native libraries during an attack, they are keen to abuse an exploitable part of the native code already used in the JCL itself. As this is not a small part (roughly 800k LOC in Java 1.7) of the JCL, a manual code review looking for security vulnerabilities is hardly an option. Automated methods have to be developed to mitigate the possible threat the native part of the JCL poses.

Clearly, not every of the roughly 1,800 native methods in the JCL constitutes a serious risk, some of them might even be completely benign. For instance, a call to java.io.FileOutputStream.write might be harmless in contrast to sun.miscUnsafe.copyMemory. So the potential threat of a native method is depending on their treatment of the input data and the resulting expected (or unexpected) side effects they produce (e.g. memory alterations, buffer overflows, …).

javas native threat - classification

In this thesis an automated code analysis has to be developed that operates on the native part of the JCL (e.g. with LLVM) and classifies the methods visible to the Java part of the JCL according to their potential threat. Different input data for this classification can be utilized here. Interesting signals might be (and are not limited to) functional purity, direct memory manipulations, pointer arithmetics or type misuses. Basically anything from current exploit literature can be applied here to achieve more precise and meaningful results.

You will find the original thesis description on the institute’s website. If you are a CS student of TU Darmstadt, please contact me if you are interested in making this topic the topic of your Bachelor or Master’s thesis.

Student thesis project: Charting and characterizing data flows between the Java and the native part of the JCL

The Java Class Library (JCL) – with Java being one of the majorly adopted programming languages – is heavily used and an implicitly trusted library on which many mission critical applications are based. In order to prevent abuse, Java has a sophisticated security model to ensure the isolation of protected areas inside a program. However, attackers have found and continue to find several ways to disable the security model thus rendering it useless.

One way of effectively evading the Java Security Model is to perform operations in native code. Since attackers cannot easily introduce new native libraries during an attack, they are keen to abuse an exploitable part of the native code already provided by the JCL itself. As this is not a small part (roughly 800k LOC in Java 1.7) of the JCL, a manual code review looking for security vulnerabilities is hardly an option. Automated methods have to be developed to mitigate the possible threat the native part of the JCL poses.

When constructing an attack against the Java Security Model using the native part of the JCL most attacks use specially crafted input sent through Java methods to the native part. This crafted input might break the native part and thus enable the Java part of the exploit to deactivate the Java Security Model (e.g. CVE-2013-2465) and continue in full privileged mode. Choosing an Applet as the delivery method for the exploit the number of possible targets easily becomes interesting for an attacker.

javas native threat - dataflows

In this thesis an automated analysis of the data flows between the VM-controlled and the native part of the JCL has to be created. As it will be hard to cross the language boundary between the VM-controlled and the native part with an analysis, the analysis may run in two steps. One step analyzing the Java part of the JCL (e.g. with Soot) and another step analyzing the native part of the JCL (e.g. with LLVM). The results of both analysis steps then have to be combined to produce an overall result. A classification schema has to be developed to characterize data flows depending on their possible exploitability. For instance, some safe guards and input sanitizers might mitigate threats well, while others might not. Additionally, certain data types could be more prone to exploitation than other data types. However, some parameters of the Java Native API might not even be accessible for an attacker at all.

You will find the original thesis description on the institute’s website. If you are a CS student of TU Darmstadt, please contact me if you are interested in making this topic the topic of your Bachelor or Master’s thesis.

Student thesis project: Modelling the use of native methods in the Java Class Library

As announced earlier, I will present some ideas for student theses here. Feel free to comment on them.

The Java Class Library (JCL) – with Java being one of the majorly adopted programming languages – is heavily used and an implicitly trusted library on which many mission critical applications are based. In order to prevent abuse, Java has a sophisticated security model to ensure the isolation of protected areas inside a program. However, attackers have found and continue to find several ways to disable the security model thus rendering it useless.

One way of effectively evading the Java security model is to perform operations in native code. Since attackers cannot easily introduce new native libraries during an attack, they are keen to abuse an exploitable part of the native code already used in the JCL itself. As this is not a small part (roughly 800k LOC in Java 1.7) of the JCL, a manual code review looking for security vulnerabilities is hardly an option. Automated methods have to be developed to mitigate the possible threat the native part of the JCL poses.

Currently, users of the public API of the JCL are completely oblivious of the fact that most of their method calls will sooner or later result in a native call. Thus, they rely on the JCL to perform any checks or sanitization necessary. The non-native part of the JCL therefore endows the trust of application developers using it.

As the JCL and its native part have grown over the years of its existence, security reviews became increasingly complicated to perform purely by hand. Oracle, as one of the larger contributors to Java, runs code analysis tools to aid these reviews. Due to the complex nature of the Java security model and the architecture of the JCL finding vulnerabilities is a rather tough problem.

javas native threat - modelling

In this thesis an implementation of an automated static code analysis has to be created that is able to evaluate the propagation of the possible threat native calls pose to the public API of the JCL. Assuming that every native method poses the same amount of threat, the propagation of this threat is solely depending on the data provided to these method. Therefore, the analysis will largely benefit on an elaborate rating of the data, its type, safe guards on that data and possible treatments applied to it. In order to combine this information, techniques from data mining, machine learning, graph or network theory can be applied to the transitive hull of the reverse call graph (around 95.000 methods) of native methods (around 1800 methods) in the JCL. After a successful analysis run it should be possible to determine the risk of calling methods of the JCL. Developers can then take effective countermeasures while processing user input and make educated choices on the classes and methods they are using.

You will find the original thesis description on the institute’s website. If you are a CS student of TU Darmstadt, please contact me if you are interested in making this topic the topic of your Bachelor or Master’s thesis.