|Summary:||[QE] (6.4.0) Resteasy secure processing to be turn on by default to apply entity expansion limit|
|Product:||[JBoss] JBoss Enterprise Application Platform 6||Reporter:||Katerina Odabasi <kanovotn>|
|Component:||RESTEasy||Assignee:||Ron Sigal <rsigal>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Katerina Odabasi <kanovotn>|
|Version:||6.3.0||CC:||kanovotn, rsigal, weli|
|Target Release:||EAP 6.4.0|
|Fixed In Version:||Doc Type:||Bug Fix|
Two new RESTEasy parameters have been created to improve security in processing `org.w3c.dom.Document` documents. Both are `context-param` parameters and configured in the `web.xml` configuration file of the application. Name: resteasy.document.secure.processing.feature Default value: true Description: Impose security constraints in processing org.w3c.dom.Document documents and JAXB object representations Name: resteasy.document.secure.disableDTDs Default value: true Description: Prohibit DTDs in org.w3c.dom.Document documents and JAXB object representations Note that Xerces 2.9.1.redhat-6 included in EAP 6.4.0 doesn't support Max attributes limit.
|:||1108548 (view as bug list)||Environment:|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
|Bug Blocks:||1108548, 1165127|
Description Katerina Odabasi 2014-04-23 12:38:00 UTC
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): 6.3.0.ER2 How reproducible: always 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 Actual results: The response is 200 (OK) instead of Expected results: status: 400 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> Additional info: 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.
Comment 1 Katerina Odabasi 2014-06-09 08:31:25 UTC
----- Original Message ----- From: "Ron Sigal" <firstname.lastname@example.org> To: "Katerina Novotna" <email@example.com> Cc: "Stuart Douglas" <firstname.lastname@example.org>, "Kabir Khan" <email@example.com>, "Pavel Slavicek" <firstname.lastname@example.org>, "Rostislav Svoboda" <email@example.com>, "Arun Neelicattu" <firstname.lastname@example.org>, "Bill Burke" <email@example.com>, "Weinan Li" <firstname.lastname@example.org> 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'>" + "<!ENTITY foo1 '&foo;&foo;&foo;&foo;&foo;&foo;&foo;&foo;&foo;&foo;'>" + "<!ENTITY foo2 '&foo1;&foo1;&foo1;&foo1;&foo1;&foo1;&foo1;&foo1;&foo1;&foo1;'>" + "<!ENTITY foo3 '&foo2;&foo2;&foo2;&foo2;&foo2;&foo2;&foo2;&foo2;&foo2;&foo2;'>" + "<!ENTITY foo4 '&foo3;&foo3;&foo3;&foo3;&foo3;&foo3;&foo3;&foo3;&foo3;&foo3;'>" + "<!ENTITY foo5 '&foo4;&foo4;&foo4;&foo4;&foo4;&foo4;&foo4;&foo4;&foo4;&foo4;'>" + "<!ENTITY foo6 '&foo5;&foo5;&foo5;&foo5;&foo5;&foo5;&foo5;&foo5;&foo5;&foo5;'>" + ... "]>"; String small = doctype + "<favoriteMovieXmlRootElement><title>&foo4;</title></favoriteMovieXmlRootElement>"; String big = doctype + "<favoriteMovieXmlRootElement><title>&foo5;</title></favoriteMovieXmlRootElement>"; 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.
Comment 2 Scott Mumford 2014-07-04 00:56:46 UTC
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)?
Comment 3 Katerina Odabasi 2014-07-04 07:54:59 UTC
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.
Comment 4 Scott Mumford 2014-07-07 21:17:10 UTC
Thanks Katerina. 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)
Comment 5 Carlo de Wolf 2014-07-21 18:11:44 UTC
*** Bug 1108548 has been marked as a duplicate of this bug. ***
Comment 6 Ron Sigal 2014-07-22 02:02:59 UTC
Did we decide that the problem should be handled in Resteasy rather than globally?
Comment 9 Ron Sigal 2014-07-30 04:20:55 UTC
Hi Katerina, 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? -Ron
Comment 10 Katerina Odabasi 2014-08-12 11:21:20 UTC
Hi Ron, 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?
Comment 11 Ron Sigal 2014-08-13 23:11:00 UTC
Hi Katerina, 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(); spf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); ... 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 email@example.com. Maybe he has something to add. I'll email him. -Ron
Comment 12 Ron Sigal 2014-09-18 18:35:56 UTC
I have submitted PR https://github.com/resteasy/Resteasy/pull/582 for https://issues.jboss.org/browse/RESTEASY-1055.
Comment 13 JBoss JIRA Server 2014-10-23 23:00:14 UTC
Ron Sigal <firstname.lastname@example.org> updated the status of jira RESTEASY-1055 to Resolved
Comment 14 JBoss JIRA Server 2014-10-23 23:35:49 UTC
Ron Sigal <email@example.com> updated the status of jira RESTEASY-1055 to Closed
Comment 17 Katerina Odabasi 2014-11-21 14:50:05 UTC
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 https://bugzilla.redhat.com/show_bug.cgi?id=1166720 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 Tests: org.jboss.resteasy.test.resteasy1055.TestSecureProcessing org.jboss.resteasy.test.xxe.TestXXESecureProcessing org.jboss.resteasy.test.xxe.TestSecureProcessingFeature
Comment 18 Katerina Odabasi 2014-11-21 14:51:33 UTC
Verified in EAP 6.4.0.DR10.