Java applets running inside a browser, sandboxed by the JSM
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?
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)
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
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?
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
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
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?
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?
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
Upload a JSP shell to achieve RCE
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/
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
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
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
Jenkins XML API uses XStream to deserialize input
Access to XML API -> RCE (but not such a huge deal)
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/
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