Description of problem:
TestXXESecureProcessing testcase fails on the following tests:
Failed tests: testXmlRootElementWithExternalExpansionBig(org.jboss.resteasy.test.xxe.TestXXESecureProcessing): expected:<400> but was:<200>
testXmlRootElementDefaultBig(org.jboss.resteasy.test.xxe.TestXXESecureProcessing): expected:<400> but was:<200>
testXmlRootElementWithoutExternalExpansionBig(org.jboss.resteasy.test.xxe.TestXXESecureProcessing): expected:<400> but was:<200>
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. git clone https://github.com/resteasy/Resteasy.git resteasy-ts; cd resteasy-ts
2. uncomment xercesImpl dependency in resteasy-jaxb-provider project pom
3. mvn clean verify -fn -pl :resteasy-jaxb-provider,:resteasy-test-tjws,:tjws -Dtest=TestXXESecureProcessing
The response is 200 (OK) instead of
Result: <HTML><HEAD><TITLE>400 javax.xml.bind.UnmarshalException</TITLE></HEAD><BODY BGCOLOR="#D1E9FE"><H2>400 javax.xml.bind.UnmarshalException</H2><PRE>
- with linked exception:
[org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; JAXP00010001: The parser has encountered more than "64000" entity expansions in this document; this is the limit imposed by the JDK.]</PRE><HR><ADDRESS><A HREF="http://tjws.sourceforge.net">D. Rogatkin's TJWS based on Acme.Serve Version 1.70, $Revision: 1.194 $</A></ADDRESS></BODY></HTML>
The tests fails on any platform, with xercesImpl project dependency defined. It fails with xerces:xercesImpl:2.9.1-redhat-4 provided by EAP and also with xerces:xercesImpl:2.9.1 upstream dependecy.
----- Original Message -----
From: "Ron Sigal" <email@example.com>
To: "Katerina Novotna" <firstname.lastname@example.org>
Cc: "Stuart Douglas" <email@example.com>, "Kabir Khan" <firstname.lastname@example.org>, "Pavel Slavicek" <email@example.com>, "Rostislav Svoboda" <firstname.lastname@example.org>, "Arun Neelicattu" <email@example.com>, "Bill Burke" <firstname.lastname@example.org>, "Weinan Li" <email@example.com>
Sent: Friday, June 6, 2014 9:44:29 PM
Subject: Re: XML eXternal Entity (XXE) - does expand always in particular testcase
2. A DOS attack can be based on the expansion of a very large entity,
external or internal, possibly causing buffer overruns. For example,
String doctype =
"<!DOCTYPE foodocument [" +
"<!ENTITY foo 'foo'>" +
String small = doctype +
String big = doctype +
in TestXXESecureProcessing. Now, if
"resteasy.document.expand.entity.references" is set to false, there's no
problem. But if it's not set to false, the usual unmarshaling process
takes place in AbstractJAXBProvider. Now, JAXP has an
"entityExpansionLimit" parameter, which is supposed to default to 64000,
which causes an Exception to be thrown if too many expansions occur.
That's the reason I contacted you in the first place, since our version
of xerces doesn't enforce that limit.
https://jaxp.java.net/1.4/JAXP-Compatibility.html says that the limit
takes effect if the "secure processing feature" is turned on, and it
also says that the secure processing feature should be turned on by
default. Apparently, that doesn't happen in our version of xerces.
This problem should be listed in known issues for EAP 6.3.0.
Set the Target Release to TBD EAP 6 so that this bug appears in Release Notes dashboards and can be included as required.
Ron,Katerina, could you please supply some information about this issue for inclusion in the 6.3.0 Release Notes (Known Issues)?
Hi Scott, here is brief summary:
Module xercesImpl version 2.9.1-redhat-5 which is currently present in EAP, has secure processing feature turned off by default. This setting allows external or internal XML entities to be expanded without an expansion limit.
Therefore responsibility to enable secure processing lies with the application that uses xerces. Resteasy should provide a parameter to set secure processing feature on.
I've added a release note text and marked this for inclusion in the 6.3.0 Release Notes.
I've also changed the Target Release to 6.4.0 to ensure this gets picked up in our Release Note filters. Feel free to return it to TBD 6 after the 6.3.0 GA.
(Also clearing NEEDINFO)
*** Bug 1108548 has been marked as a duplicate of this bug. ***
Did we decide that the problem should be handled in Resteasy rather than globally?
I don't have a strong opinion. Here's what Arun said on bz 1108548:
> Unfortunately the answer to this is rather messy. In my personal view, turning this off by default and enabling it either in application contexts as required and allowing it to be configurable via a global option is the correct thing to do. I have heard it being argued that responsibility to enable secure processing lies with the application that uses xerces and not the server/platform. However, I think the problem should be resolved that the lowest level, which in this case is disable globally by default.
> If enabling secure processing by default, I would call this a defense in depth measure rather than a vulnerability since this is something the customers can enable within their apps and EAP itself does not expose a vector that allows an attacker to exploit this (excluding the flaw being handled). Either way, I recommend this be handled as a Red Hat Internal issue.
To be honest, I'm not sure I understand the comment. It sounds like Arun is suggesting
1. Install a global parameter to turn on secure processing
2. Set the default value to false.
Is that how you read it?
yeah, I understand same as well. I think important is that it will be configurable. And IMHO it makes more sense from global level since xerces module is not used only by Resteasy, Am I right?
I certainly guess that other projects use xerces, but I don't know that for a fact.
As far as I know, the way to turn on secure processing is to do something like
SAXParserFactory spf = SAXParserFactory.newInstance();
That is, the setting would specific to a particular parser. I don't know if there's a way to turn it on globally. So, I would end up doing the same thing whether the parameter is defined in Resteasy or somewhere else. In fact, I don't know where it would be appropriate to define a global parameter like that. Do you?
In principle, though, I think it would make sense that any module that uses xerces and is at risk from XXE attacks should turn on secure processing, so, in that sense, it makes sense to make the parameter global.
You know, I just looked at https://jaxp.java.net/1.4/JAXP-Compatibility.html again, and was reminded of the assertion, "In JAXP 1.4, the secure processing feature is turned on by default". Why don't we consider it a bug that it isn't turned on? I found a reference to https://bugzilla.redhat.com/show_bug.cgi?id=1022300, "Build source jar for xercesImpl-2.9.1", assigned to firstname.lastname@example.org. Maybe he has something to add. I'll email him.
I have submitted PR https://github.com/resteasy/Resteasy/pull/582 for https://issues.jboss.org/browse/RESTEASY-1055.
Ron Sigal <email@example.com> updated the status of jira RESTEASY-1055 to Resolved
Ron Sigal <firstname.lastname@example.org> updated the status of jira RESTEASY-1055 to Closed
The new Secure processing parameters must be documented in EAP Resteasy documentation - https://bugzilla.redhat.com/show_bug.cgi?id=1165127
The default behaviour changed:
1) by default xml documents with DTD are not allowed -> setting resteasy.document.secure.disableDTDs to false in web.xml is needed to allow it.
2) by default secure processing is set to true -> setting resteasy.document.secure.processing.feature to false in web.xml is needed to disable it.
This needs to be mentioned in release notes
Xerces 2.9.1.redhat-6 included in EAP 6.4.0 doesn't support Max atributtes limit https://bugzilla.redhat.com/show_bug.cgi?id=1148739
Verified in EAP 6.4.0.DR10.