Bug 1104497

Summary: xercesImpl not turn on the secure processing feature by default
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Yong Yang <yyang>
Component: RESTEasyAssignee: Yong Yang <yyang>
Status: CLOSED DUPLICATE QA Contact: Katerina Odabasi <kanovotn>
Severity: high Docs Contact:
Priority: high    
Version: 6.3.0CC: dwalluck, fnasser, pgier, weli
Target Milestone: ---   
Target Release: EAP 6.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-07-16 11:07:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Yong Yang 2014-06-04 07:24:34 UTC
Description of problem:

From "Ron Sigal" <rsigal@redhat.com> 's mail thread: "Another XXE issue".

------------

From: "Ron Sigal" <rsigal@redhat.com>
To: pjanouse@redhat.com, pjanouse@redhat.com
Cc: "Bill Burke" <bburke@redhat.com>, "Weinan Li" <weli@redhat.com>
Sent: Sunday, June 1, 2014 5:46:39 AM
Subject: Another XXE issue

Hi Pavel and David,

I've been looking at RESTEASY-1055 "TestXXESecureProcessing testcase
doesn't throw UnmarshalException", and I'm writing to you because you
were both involved with JBPAPP-8055, which concerned XXE attacks.  It
seems that different implementations of Xerces treat external entity
expansion differently.  JAXP specifies a default limit of 64000 for the
entityExpansionLimit parameter "when the secure processing feature is
on", but different implementations seem to handle entityExpansionLimit
differently. In particular, the version that ships with JDK 1.7 (which I
tested with originally) applies the limit (and throws an Exception when
it is violated) even when secure processing is turned off, but
"xerces:xercesImpl:2.9.1-redhat-4 provided by EAP", referred to by
RESTEASY-1055, ignores the limit when secure processing is turned off.

It seems that I need to turn on secure processing explicitly to ensure
that the entity expansion limit is observed, but I don't want to change
the existing behavior of Resteasy, so I propose to add a Resteasy
parameter, "resteasy.document.secure.processing", that can be used to
turn on secure processing.  If it is set to true, then it looks like I
have to use a wrapping unmarshaller like I did to prevent entity expansion.

Any comments?

-Ron

-----------

On 06/02/2014 08:44 AM, "Katerina Novotna" <kanovotn@redhat.com> wrote:

Hi Ron,

I'm thinking it is already late to include this fix to EAP 6.3.0. I propose to document this issue to known issues for EAP 6.3.0, with proposed "workaround"
that customer application needs to check the length of the expansion.

To the resolution of the issue itself - it seems to me more like problem of the current xerces implementation present in EAP rather than problem of resteasy itself.
It seems more clean to me to fix it in xerces directly.

What do you think?

Comment 1 Yong Yang 2014-06-04 07:26:40 UTC
Xerces Prod git repo: http://git.app.eng.bos.redhat.com/git/xerces2-j.git/

Comment 2 Katerina Odabasi 2014-07-16 11:07:39 UTC
Dublicate to https://bugzilla.redhat.com/show_bug.cgi?id=1108548

*** This bug has been marked as a duplicate of bug 1108548 ***