Category Archives: Vulnerability

Getting to Know You… Towards a Capability Model for Java

Have you ever wondered what system resources the library you are about to include into your software project uses?

When you are developing software and care for the security of your system, you are in a dilemma: Either you use off-the-shelf software components and don’t know what might happen or either  inspect the off-the-shelf components (which might take the same time as a rewrite) and probably miss your deadlines. This is not a very enjoyable situation to be in.

We would like to change that and developed a high-level capability inference for Java libraries. It can tell you which system resources it uses, so you can sleep safely again because the math library you use will not leak your sensitive data.

Continue reading “Getting to Know You… Towards a Capability Model for Java” »

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.

Analysis of Java Exploit CVE-2013-2460

Lately I’ve been looking very much into the Java Security model as the news coverage is quite excessive since September 2012. Today I took a closer look at  issue CVE-2013-2460.

In principle these exploits all work more or less in the same way. Usually, they come in the form of an applet that can be easily delivered to the possible victims with a web site.  These applets now try to break the sandboxing security model of Java. In order to do this, they use functionality of the JCL that is not properly checked. These in turn provide access to security critical functionality that is used to break applet encapsulation. We call them “Confused Deputies” with respect to the definition of Norm Hardy.

In CVE-2013-2460, these are calls to java.lang.reflect.InvocationHandler, which is an interface.  The used instance has the concrete type sun.tracing.NullProvider, but the interesting method is implemented in its superclass sun.tracing.ProviderSkeleton.

Here, the method Method.invoke is called. This method does not implement any checks whether a public method should be invoked. Therefore, also security critical, caller-sensitive methods can be called with this proxy.

This was actually fixed after Java 7u21 with the following lines:


Class localClass = paramMethod.getDeclaringClass();
...
if ((localClass == Provider.class) || (localClass == Object.class))
...

Using this vulnerability three classes are being loaded:

sun.org.mozilla.javascript.internal.Context
sun.org.mozilla.javascript.internal.DefiningClassLoader
sun.org.mozilla.javascript.internal.GeneratedClassLoader

They are then being used to create objects of the type MethodHandle that point to the following methods:

Context.enter
Context.createClassLoader
DefiningClassLoader.defineClass

To get this to work, the exploit is using a very mean trick…

Using the InvocationHandler the method MethodHandles.lookup is called. This leaks a reference to the class Lookup, which also falls under the Confused Deputy category.

This class is somehow infamous for such nice implementations as this: 

/* Obtain the external caller class, when called from Lookup.<init> or
*  a first-level subroutine. */
private static Class<?> getCallerClassAtEntryPoint(boolean inSubroutine) {
final int CALLER_DEPTH = 4;

// Stack for the constructor entry point (inSubroutine=false):
//   0: Reflection.getCC, 1: getCallerClassAtEntryPoint,
//   2: Lookup.<init>, 3: MethodHandles.*, 4: caller
// The stack is slightly different for a subroutine of a
// Lookup.find* method:
//   2: Lookup.*, 3: Lookup.find*.*, 4: caller
// Note:  This should be the only use of getCallerClass in this file.

assert(Reflection.getCallerClass(CALLER_DEPTH-2) == Lookup.class);
assert(Reflection.getCallerClass(CALLER_DEPTH-1) == (inSubroutine ? Lookup.class : MethodHandles.class));
return Reflection.getCallerClass(CALLER_DEPTH);
}

And just this small and benign looking return statement in the last line of code is spreading the misery here. It SHOULD return the calling class but in fact is returning sun.tracing.ProviderSkeleton in this case…

Which is of course highly privileged… Red Alert!

Then the usual stuff happens… A fresh ClassLoader is used to load and create a class from a byte array, that of course includes some highly miserable code, namely:


System.setSecurityManager(null);

That loaded class of course is privileged as the ProviderSkeleton itself is. The SecurityManager is then disabled and disaster may begin…

You will find the code for this exploit as well as other exploits in the Java Exploit Library I am maintaining with Johannes Lerch.

Also, here is a very interesting report on the exploit provided by Security Explorations, a Polish team concerned with Java security since 2002.

 

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.

Java Exploit Library started

Today, Johannes Lerch and I started a public bitbucket project to collect and categorize example code from Java-related exploits. It should help researchers and students to develop effective detection and prevention techniques against them.

To construct this library of exploits, we gather information from different public analysis reports and attribute the authors of the original reports, so everything can be tracked back.

Feel free to comment, use the exploit code to develop your own countermeasures, perform pull request if you want to add or correct a thing.

Link: Java Exploit Library Project