Bug 1090487 - [QE] (6.4.0) Resteasy secure processing to be turn on by default to apply entity expansion limit
Summary: [QE] (6.4.0) Resteasy secure processing to be turn on by default to apply ent...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: RESTEasy
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: DR9
: EAP 6.4.0
Assignee: Ron Sigal
QA Contact: Katerina Odabasi
URL:
Whiteboard:
: 1108548 (view as bug list)
Depends On:
Blocks: 1108548 1165127
TreeView+ depends on / blocked
 
Reported: 2014-04-23 12:38 UTC by Katerina Odabasi
Modified: 2019-08-19 12:41 UTC (History)
3 users (show)

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.
Clone Of:
: 1108548 (view as bug list)
Environment:
Last Closed:
Type: Bug
smumford: needinfo-


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1014393 None None None Never
Red Hat Bugzilla 1104497 None None None Never
Red Hat One Jira Issue Tracker RESTEASY-1055 Major Closed Resteasy secure processing to be turn on by default to apply entity expansion limit 2018-02-16 07:50:24 UTC

Internal Links: 1014393 1104497

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

-Ron

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
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.


Note You need to log in before you can comment on or make changes to this bug.