Secure XML Processing with JAXP on EAP 7

This article was originally published on the Red Hat Customer Portal. The information may no longer be current.

The Java Development Kit (JDK) version 8 provides the Java API for XML Processing (JAXP). If a developer is using JAXP on Red Hat JBoss Enterprise Application Platform (EAP) 7 they need to be aware that Red Hat JBoss EAP 7 ships it's own implementation, with some differences from JDK 8 that are covered in this article.

Background

There have been three issues raised in the month of May 2017 relating to JAXP on Red Hat JBoss EAP 7: CVE-2017-7464, CVE-2017-7465, and CVE-2017-7503. All of the issues are XML External Entity (XXE) vulnerabilities, which have affected Java since 2002. XXE is a type of attack that affects weakly configured XML parsers. A successful attack occurs when XML input contains external entities. Those external entities can do things such as access local network resources, or read local files.

Red Hat maintains it's own fork of Xalan used for XML processing. This was done to avoid certain limitations with the upstream code in a multi-classloader, modular environment, such as Red Hat JBoss EAP. The JDK maintains it's own fork as well, and has made some security improvements which have not been contributed back to the upstream Xalan project. For example a Billion Laughs-style XXE attack is thwarted on OpenJDK 1.8.0_73 by changes that result in an error message such as:

JAXP00010001: The parser has encountered more than "64000" entity expansions in this document; this is the limit imposed by the JDK.

It's important to remember that you only need to be concerned about vulnerabilities affecting XML processing if you don't trust the XML content you are parsing. One way to add trust to XML content is by adding authentication to network-accessible endpoints which are accepting XML content.

The current situation

All of the vulnerabilities relate to JAXP and not to the Web Services specifications JAX-WS and JAX-RS. JAX-WS and JAX-RS are implemented on Red Hat JBoss EAP by Apache CXF and Resteasy. One of the main goals for developers on Red Hat JBoss EAP is to build web services, which is why the distinction is made. If you're doing web service development on Red Hat JBoss EAP 7, these issues will mostly not apply. They affect the use of JAXP directly for XML processing.

There is one place where web services overlap with JAXP, and user code could potentially be affected by one of these vulnerabilities. Section 4.2.4 of the JAX-RS 2.0 specification mandates that EAP 7 must provide MessageBodyReader, and MessageBodyWriter implementations for javax.xml.transform.Source. This is used for processing of JAX-RS requests with application/*+xml media types. A common way of unmarshaling a javax.xml.transform.Source is to use a TransformerFactory as demonstrated here:

TransformerFactory factory = TransformerFactory.newInstance();
Transformer transformer = factory.newTransformer();
StreamResult xmlOutput=new StreamResult(new StringWriter());
transformer.transform(mySource,xmlOutput);
resultXmlStr = xmlOutput.getWriter().toString();

Where mySource is of type javax.xml.transform.Source.

In this situation, there is one outstanding issue, CVE-2017-7503, on EAP 7.0.5 which is yet to be resolved. While this is one place where Red Hat JBoss EAP encourages the use of JAXP, the JAX-RS implementation (Resteasy) is not directly affected. Resteasy is not directly affected because it doesn't do any processing of a javax.xml.transform.Source as demonstrated above. It only provides a javax.xml.transform.Source for the developer to transform in their web application code.

CVE-2017-7503 affects processing of XML content from an untrusted source using a javax.xml.transform.TransformerFactory. The only safe way to process untrusted XML content with a TransformerFactory is to use the StAX API. StAX is a safe implementation on EAP 7.0.x because the XML content is not read in it's entirety in order to parse it. As a developer using StAX, you decide which XML stream events you want to react to, so XXE control constructs won't be processed automatically by the parser.

For CVE-2017-7464 and CVE-2017-7465 there are mitigations from OWASP XXE Prevention Cheat Sheet. The specific mitigation for these issues are as follows:

CVE-2017-7464

SAXParserFactory parserFactory = SAXParserFactory.newInstance();
parserFactory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
parserFactory.setFeature("http://apache.org/xml/features/disallow-doctype-decl",
             true);

CVE-2017-7465

TransformerFactory factory = TransformerFactory.newInstance();
factory.setFeature(javax.xml.XMLConstants.FEATURE_SECURE_PROCESSING, true);

How could it be fixed?

On Red Hat JBoss EAP 7.0.x, CVE-2017-7503 is yet to be resolved. In contrast CVE-2017-7464 and CVE-2017-7465 already have mitigations in place so a fix may not be provided in the 7.0.x stream.

Ideally, JAXP implementations would be removed entirely from Red Hat JBoss EAP 7 and rely solely on those from the JDK itself. Removing Xalan from Red Hat JBoss EAP is still being investigated.

A compromise might be to maintain a fork of the JAXP libraries and enable the secure options recommended by OWASP by default in a future major release of Red Hat JBoss EAP 7.