Write once, run anywhere

a tour of java remote code execution vectors

what this talk is not about

Java applets running inside a browser, sandboxed by the JSM

what this talk is about

Remotely exploitable code execution flaws in Java applications running on application servers like Tomcat, JBoss, GlassFish, etc. with no JSM

  • Various XSL libraries allow embedding code in stylesheets via extensions

  • Xalan and Saxon allow embedding Java code

  • Xalan allows this by default, unless explicitly disabled

  • Even then, there are workarounds:  https://access.redhat.com/security/cve/CVE-2014-0107

  • How can an attacker supply XSL?

xsl extensions

  • camel-xslt transforms: http://camel.apache.org/xslt

  • Attacker can provide an XML document, but how about the XSL file?

  • CamelXsltFileName message header (accepts URIs)

  • Live demo

xsl extensions: camel

Camel empowers you to define routing and mediation rules in a variety of domain-specific languages, including a Java-based Fluent API, Spring or Blueprint XML Configuration files, and a Scala DSL.

  • Ektron CMS, user-supplied XSL without authentication (CVE-2012-5357)

  • Liferay, XSL portlets (CVE-2011-1571)

  • One more of my own, should be unembargoed in time for Ruxcon

xsl extensions: other examples

  • Various expression languages are commonly used in Java libraries

  • MVEL is one example

  • Generally speaking, if an attacker can supply EL, they can execute arbitrary code on the server

  • How can an attacker supply EL?

el interpolation

The EL 2.2 spec allows method invocation, which permits an attacker to execute arbitrary code within context of the application. This can manipulate application functionality, expose sensitive data, and branch out into system code access-- posing a risk of server compromise.

  • Zanata is an open-source translation memory platform built on Seam

  • Seam evaluates EL in log messages. If code performs string concatenation with user-supplied input to create the log messages, an attacker can inject EL (Credit: Adrian Hayes)

  • Zanata logged user-supplied strings using string concatenation

EL interpolation: zanata

  • Elasticsearch enables MVEL embedded in search queries by default

  • This is a feature, and the environment is meant to be protected

  • In many environments, of course, it is not.

  • Example: JBoss Fuse: https://access.redhat.com/solutions/1191453

  • Live Demo

el interpolation: elasticsearch

  • Java contains a native serialization mechanism, which converts objects to binary data

  • When deserializing, the readObject() and readResolve() methods of the class will be called

  • This can lead to vulnerabilities if a class on the classpath has something exploitable in readObject() or readResolve()

  • How can an attacker provide binary serialized objects?

binary deserialization

  • Serialization is used as a format for transferring objects over networks, e.g. via REST APIs

  • Example #1: RichFaces state (CVE-2013-2165, Takeshi Terada, MBSD)

  • Example #2: Restlet REST framework (CVE-2013-4271)

  • What kind of issue could exist in readResolve()/readObject() that would be exploitable?

binary deserialization

  • Component to simplify file uploads in Java apps

  • DiskFileItem class implements readObject()

  • The readObject() method creates a tmp file on disk: tempFile = new File(tempDir, tempFileName);

  • tempDir is read from the repository private attribute of the class, exposing a poison null byte flaw (file-writing code is native, now patched)

  • An attacker can provide a serialized instance of DFI with a null-terminated full path value for the repository attribute: /path/to/file.txt\0

  • commons-fileupload code embedded in Tomcat

binary deserialization: Apache commons fileupload

  • Upload a JSP shell to achieve RCE

  • Live demo

  • Solution #1: don't deserialize untrusted content

  • Solution #2: don't introduce flaws in readObject()/readResolve()

  • Solution #3: type checking with look-ahead deserialization (Pierre Ernst): http://www.ibm.com/developerworks/java/library/se-lookahead/index.html

  • More information: https://securityblog.redhat.com/2013/11/20/java-deserialization-flaws-part-1-binary-deserialization/

binary deserialization: Restlet + dfi

  • Alternative XML-based serialization formats

  • JAXB is the standard (no known flaws)

  • Other XML serialization libraries exist, and have exposed security issues leading to RCE vulnerabilities

  • We'll look at two examples: XMLDecoder and XStream

xml deserialization

  • Various XMLDecoder's XML format can represent a series of methods that will be called to reconstruct an object

  • If XMLDecoder is used to deserialize untrusted input, arbitrary code can be injected into the XML





  • Example: Restlet (CVE-2013-4221) - fixed by removing vulnerable functionality

xml deserialization: XMLDecoder

  • Reflection-based deserialization

  • Has a special handler for dynamic proxies (implementations of interfaces)

  • Attackers can provide XML representing a dynamic proxy class, which implements the interface of a class the application might expect

  • Dynamic proxy implements a handler that calls arbitrary code when any members of the deserialized class are called

  • Vulnerable components: Spring OXM, Sonatype Nexus, Jenkins

xml deserialization: xstream

  • Jenkins XML API uses XStream to deserialize input

  • Access to XML API -> RCE (but not such a huge deal)

  • Live demo

  • Solution: blocked DynamicProxyConverter in XStream wrapper class

  • Upstream solution: whitelisting, with dynamic proxies excluded by default

  • More information: https://securityblog.redhat.com/2014/01/23/java-deserialization-flaws-part-2-xml-deserialization/

xml deserialization: jenkins

  • XXE background

  • Java param entities issue OWASP guide

  • RCE via theft of plaintext credentials (common)

  • gopher:// in JDK 5 allows an attacker to upload arbitrary files to the server

  • Combined with other issues, this can lead to RCE

  • Live demo

xXE + gopher



XSL Extensions