----- Original Message -----
From: "Ron Sigal" <rsigal>
To: "Katerina Novotna" <kanovotn>
Cc: "Stuart Douglas" <sdouglas>, "Kabir Khan" <kkhan>, "Pavel Slavicek" <pslavice>, "Rostislav Svoboda" <rsvoboda>, "Arun Neelicattu" <abn>, "Bill Burke" <bburke>, "Weinan Li" <weli>
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.

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.

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)

*** 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?

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

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?

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

-Ron

I have submitted PR https://github.com/resteasy/Resteasy/pull/582 for https://issues.jboss.org/browse/RESTEASY-1055.

Ron Sigal <ron.sigal> updated the status of jira RESTEASY-1055 to Resolved

Ron Sigal <ron.sigal> 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
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

Verified in EAP 6.4.0.DR10.