Bug 1090487

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: RESTEasyAssignee: Ron Sigal <rsigal>
Status: CLOSED CURRENTRELEASE QA Contact: Katerina Odabasi <kanovotn>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.3.0CC: kanovotn, rsigal, weli
Target Milestone: DR9Flags: smumford: needinfo-
Target Release: EAP 6.4.0   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of:
: 1108548 (view as bug list) Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
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):

How reproducible:

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 &quot;64000&quot; 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" <rsigal@redhat.com>
To: "Katerina Novotna" <kanovotn@redhat.com>
Cc: "Stuart Douglas" <sdouglas@redhat.com>, "Kabir Khan" <kkhan@redhat.com>, "Pavel Slavicek" <pslavice@redhat.com>, "Rostislav Svoboda" <rsvoboda@redhat.com>, "Arun Neelicattu" <abn@redhat.com>, "Bill Burke" <bburke@redhat.com>, "Weinan Li" <weli@redhat.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'>" +
                "<!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 + 
    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.

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?


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 dosoudil@redhat.com. Maybe he has something to add. I'll email him.


Comment 13 JBoss JIRA Server 2014-10-23 23:00:14 UTC
Ron Sigal <ron.sigal@jboss.com> updated the status of jira RESTEASY-1055 to Resolved

Comment 14 JBoss JIRA Server 2014-10-23 23:35:49 UTC
Ron Sigal <ron.sigal@jboss.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

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


Comment 18 Katerina Odabasi 2014-11-21 14:51:33 UTC
Verified in EAP 6.4.0.DR10.