Bug 1104497 - xercesImpl not turn on the secure processing feature by default
Summary: xercesImpl not turn on the secure processing feature by default
Keywords:
Status: CLOSED DUPLICATE of bug 1108548
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: RESTEasy
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: EAP 6.3.0
Assignee: Yong Yang
QA Contact: Katerina Odabasi
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-04 07:24 UTC by Yong Yang
Modified: 2017-10-10 00:24 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-16 11:07:39 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1090487 None None None Never

Internal Links: 1090487

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


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