• 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

• 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

• 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