Recent Java Exploitation Techniques RUB
Recent Java Exploitation Techniques RUB
HackPra 19-06-2013
Matthias Kaiser ([email protected])
1
Recent Java Exploitation Techniques
about me
Matthias Kaiser
@matthias_kaiser
working as Lead Expert Offensive Security at Daimler TSS in Ulm
enjoying Offensive Security for 4 years now
former Java Dev, System Architect and Security Architect at EADS
doing Penetration Testing and Vulnerability Research
Found vulnerabilities in Oracle Java JRE and SAP
2003 - now
Memory Corruptions (e.g. [regenrecht], @aradpop, [Vitaliy Toropov],
@wtfuzz, @jduck)
Argument Injections (e.g. [Tavis Ormandy], [Chris Ries], [me])
2008 - now
Privileged Deserialization (e.g. @samikoivu)
Trusted Method Chaining (e.g. @samikoivu, @mihi42, @tyranido)
2012 - now
Core API abuses (e.g. [Adam Gowdiak], @sagar38, @benmmurphy)
Type Confusions (e.g. @JeroenFrijters)
HackPra - Recent Java Exploitation Techniques 4
Recent Java Exploitation Techniques
Intro to Sandbox Security
Bytecode Verifier
Security Manager and AccessController
Garbage Collector
Classloader
Bytecode Verifier
Verifies the byte code in the defineClass()-method
Checks if the bytes form a valid class (conforming the class file
description)
Makes integrity and type safety checks
Security Manager
Class defined in java.lang.SecurityManager
Instance referenced in java.lang.System (System.getSecurityManager())
Checks and grants access to sensitive operations based on permissions
Forwards permission checks to AccessController
Access Controller
Checks for permissions against the current AccessControlContext
Checks all frames on the stack
If on stack misses a permission an exception is thrown
doPrivileged() used to enter and privileged code block
Source: http://docs.oracle.com/javase/6/docs/api/java/security/AccessController.html
Access Controller
Checks for permissions against the current AccessControlContext
The following algorithm is applied (m is last call on the stack)
Source: http://docs.oracle.com/javase/6/docs/api/java/security/AccessController.html
Source: http://www.oracle.com/technetwork/java/seccodeguide-139067.html
Source: http://www.oracle.com/technetwork/java/seccodeguide-139067.html
Source: http://www.oracle.com/technetwork/java/seccodeguide-139067.html
Samis discovery:
In a case when an unprivileged class inherits from a privileged one and the
class does not overload the method that is to be called and that is pushed
onto the call stack, this will be the privileged class that will be the subject
of a permission check, not the untrusted class (*)
How it works:
A untrusted subclass can inherit trusted methods from superclass, if the
method is not overwritten
By finding interfaces methods with the same name as the inherited
methods a trusted chain can be constructed (e.g. toString combined with a
Set class)
Goal: Construct a chain of method calls originating from privileged classes
(e.g. built in classes from rt.jar)
As long as privileged code is on the stack all privileges are granted
Overview:
James exploited this vulnerability in two steps during Pwn2Own
With the first step, he was able load and initiate classes under a privileged
context using a trusted chain
With the second step he was able to create a trusted method chain using
the same exploitation technique as in Michael Schierls Rhino exploit
Summary:
For loading the JDBC drivers the ServiceLoader framework is used
Loading of JDBC drivers is done in a doPrivileged() block, thus running
under elevated privileges
ServiceLoader loads classes based on Manifest entry
James tricked the ServiceLoader to load and create an object of
com.sun.script.javascript.RhinoScriptEngine under a privileged context
By creating a trusted chain as in Michael Schierls Rhino exploit the
Sandbox escape can be accomplished
Source: http://www.contextis.com/research/blog/java-pwn2own/
Source: http://schierlm.users.sourceforge.net/CVE-2011-3544.html
Various APIs
Core API
Mostly java.lang.Class and java.lang.reflect.*
New API
Since Java 7
Implemented in java.lang.invoke.*
Overview:
Vulnerability was discovered by Security Explorations
< Java 7 update 7
Exploits a vulnerability in the MethodHandle class of the new Reflection API
Intro to MethodHandle:
The vulnerability:
Source: http://www.security-explorations.com/materials/se-2012-01-report.pdf
Vulnerability details:
MethodHandle.invokeWithArguments() is calling
MethodHandle.invokeExact()
invokeExact() is just checking the immediate caller
If the immediate caller is a trusted class (e.g. from rt.jar), arbitrary methods
of arbitrary classes can be called!
Exploitation:
Easy!
Source: http://www.security-explorations.com/materials/se-2012-01-report.pdf
Overview:
With Java 7 update 11 Click-2-Play was introduced
For Java Applets Java is asking now Do you want to run this Application?
One way getting around this Prompt was found immediately using a
serialized applet (1):
<embed object="object.ser" type="application/x-java-applet;version=1.6">
Source: http://immunityproducts.blogspot.com.ar/2013/02/keep-calm-and-run-this-applet.html
Overview:
The newest vector is to start an Java Applet using JavaWebStart
Source: http://immunityproducts.blogspot.de/2013/04/yet-another-java-security-warning-bypass.html