security issue in xerces 2.5.0 and earlier (CAN-2004-1575)

[Jay Berkenbilt <ej...@ql.org>]

I posted a question on February 24 about this but got no response, so
I would greatly appreciate some advice on the proper way to get help
on this issue.  Please note that this isn't a complaint -- just a
question to make sure I'm going about this the right way. :-)

I'm asking this question as the maintainer of the xerces packages for
Debian.

CAN-2004-1575 was described as follows:

| The XML parser in Xerces-C++ 2.5.0 allows remote attackers to cause
| a denial of service (CPU consumption) via XML attributes in a
| crafted XML document.

Since some distributions, including Debian, still support some older
versions of Xerces than the latest 2.6.0 (we also support 2.6.0), it
would be most helpful to us if we could get a patch relative to older
versions for this problem.

I have looked at all changes in the xerces-c CVS repository from
September 9 to October 14 and didn't find anything that seemed like it
could possibly be related to this kind of problem.  I also searched
the cvs log text for all files for "CAN", "CPU" and a few other useful
keywords and found nothing relevant.  I've also checked JIRA for
information about this but didn't find anything.

Apparently this problem was discovered 9or just barely in the nick of
time to be fixed in 2.6.0, as all the information I've seen on this
indicate that the remedy is to upgrade to 2.6.0.  Or perhaps it just
wasn't made public until the 2.6.0 release.  Unfortunately, some
packages, notably xerces-p, specifically require older versions, so we
have little choice but to support multiple versions of the packages.

Can someone point me to an area of code that I should be looking at?
A patch against an older version would be ideal but not necessary.  If
someone can just show me where in the code the problem was fixed in
2.6.0 as compared with 2.5.0, I can take it from there.  Some files
and CVS revisions or a date range would also help if I am to construct
the patch myself.

Thanks for any help or pointers you can provide on this, including
just telling me what I should be doing instead of posting here.

-- 
Jay Berkenbilt <ej...@ql.org>


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org

Re: security issue in xerces 2.5.0 and earlier (CAN-2004-1575)

[Jay Berkenbilt <ej...@ql.org>]

For some reason, the mailing list seems to have eaten the text
preceding my patches.  They're there in the raw message, but they
precede the mime headers.  This text was actually present in my
previous post that came out looking like only patches.  Sorry about
that.

To see the patches again, look at the previous message or check it out
in the debian bugl

<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=296432>

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

Executive Summary:

I'm attaching my analysis of the changes for CAN-2004-1575 backported
to 2.5.0 and 2.4.0 here.  I'm also attaching my patches.  My testing
doesn't reveal any problems, but I'm honestly not sure that my testing
is exercising this.  I've run the automated test suites of the
software I have that uses xerces, and I've also tested parsing a file
with an element with < 20 and > 20 attributes and duplicate
attributes.  I can't say I was able to reproduce any major performance
problems, but maybe 100 attributes isn't enough on my machine.

I would be very grateful if someone could check this over and see if
this is right.  Once that's done, I'll be able to go ahead and put the
fix into Debian, and perhaps add the information to the CVE candidate.

Here are the details.

Gareth Reakes <ga...@parthenoncomputing.com> wrote:

> Jay Berkenbilt wrote:
>
>> Can someone point me to an area of code that I should be looking at?
>> A patch against an older version would be ideal but not necessary.  If
>> someone can just show me where in the code the problem was fixed in
>> 2.6.0 as compared with 2.5.0, I can take it from there.  Some files
>> and CVS revisions or a date range would also help if I am to construct
>> the patch myself.
>>
>
> It would be in the scanners. They are in the internal directory and
> end in Scanner (EG DGXMLScanner). For DGXMLScanner the revision number
> the code was committed in was 1.54 with message
>
> "Optimized duplicated attributes checking for large number of attributes"
>
> Each of them will have the same message. I have to dash off now, but
> if you have any problems I will happily help you make some patches.

There were five files in that directory that had this message in their
logs.  I generated a patch using the following:

cvs diff -u -r 1.39 -r 1.40 XMLScanner.hpp
cvs diff -u -r 1.70 -r 1.71 XMLScanner.cpp
cvs diff -u -r 1.24 -r 1.25 WFXMLScanner.cpp
cvs diff -u -r 1.53 -r 1.54 DGXMLScanner.cpp
cvs diff -u -r 1.71 -r 1.72 IGXMLScanner2.cpp

and then read the patch to make sure I understood it.  If I understood
it correctly, XMLScanner.hpp and XMLScanner.cpp were modified to just
add a function that sets the flag toUseHashTable if there are more
than 20 attributes.  The other three files modify the code for
duplicate namespace attribute checking to use a hashtable if there are
more than 20 attributes.  The changes are pretty much the same in the
three files: we set the flag, put the old code inside if
(!toUseHashTable) and put the new code in the else.  IGXMLScanner2 has
the added logic that we only do this if fGrammarType ==
Grammar::DTDGrammarType and that we have one additional
fAttrDupChkRegistry->put call outside the loop.

Now, as far as I can tell, the code that had the problem was added to
the scanners in this change:

"Patch for bug  #20530 - Attributes which have the same expanded name are not considered duplicates. Patch by cargilld."

which occurred between 2.3.0 and 2.4.0.  This means that versions
prior to 2.4.0 will have the bug that this code fixed but will not be
susceptible to the "attribute blowup" problem.  This means only 2.4.0
and 2.5.0 are "vulnerable" to CAN-2004-1575.

In attempting to apply the patch generated above to 2.5.0 and 2.4.0,
the changes to XMLScanner.hpp and XMLScanner.cpp applied fine as did
the changes to DGXMLScanner.cpp.  In 2.5.0, there were problems with
WFXMLScanner.cpp, and in 2.4.0 there were problems with both
WFXMLScanner.cpp and IGXMLScanner2.cpp.

In 2.5.0, for WFXMLScanner.cpp, all that was needed to get the patch
to apply was to wrap the loop that checked for duplicates inside if
(attCount) {...}.

For 2.4.0, in WFXMLScanner.cpp, it was necessary to move the duplicate
checking code outside of the loop that it was in and add an inner
loop.  This was the change from revision 1.19 to 1.20.  Then wrapping
that check inside the same if block was sufficient to get most of the
patch to apply.  The extra call to fAttrDupChkRegistry->put had to be
inserted by hand because some of the code around it wasn't there, but
it seemed fairly clear where to put it.

In addition to attaching my 2.4 and 2.5 patches, I'm also attaching
the patch I generated from CVS in case looking at this with the others
makes the comparison easier.

Please let me know if there's anything else I should do here.  My goal
is to make it as easy as possible for someone to review these changes
so I can get the security fix upload into Debian right away.  Thanks!

-- 
Jay Berkenbilt <ej...@ql.org>

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org

Re: security issue in xerces 2.5.0 and earlier (CAN-2004-1575)

[Jay Berkenbilt <ej...@ql.org>]

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org

Re: security issue in xerces 2.5.0 and earlier (CAN-2004-1575)

[Jay Berkenbilt <ej...@ql.org>]

Gareth Reakes <ga...@parthenoncomputing.com> wrote:

> It would be in the scanners. They are in the internal directory and
> end in Scanner (EG DGXMLScanner). For DGXMLScanner the revision number
> the code was committed in was 1.54 with message
>
> "Optimized duplicated attributes checking for large number of attributes"
>
> Each of them will have the same message. I have to dash off now, but
> if you have any problems I will happily help you make some patches.
>
> Cheers,
>
> Gareth

Thank for the reply!

This should probably be fine, but I'll let you know if I need more
help.

It'll be great when the project finishes the CVS to subversion
migration -- then this would probably just end up as a single
revision. :-)

-- 
Jay Berkenbilt <ej...@ql.org>

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org

Re: security issue in xerces 2.5.0 and earlier (CAN-2004-1575)

[Gareth Reakes <ga...@parthenoncomputing.com>]

Hi,

Jay Berkenbilt wrote:
> I posted a question on February 24 about this but got no response, so
> I would greatly appreciate some advice on the proper way to get help
> on this issue.  Please note that this isn't a complaint -- just a
> question to make sure I'm going about this the right way. :-)

Sorry, we must have missed the post - I don't recall it.


> Can someone point me to an area of code that I should be looking at?
> A patch against an older version would be ideal but not necessary.  If
> someone can just show me where in the code the problem was fixed in
> 2.6.0 as compared with 2.5.0, I can take it from there.  Some files
> and CVS revisions or a date range would also help if I am to construct
> the patch myself.
> 

It would be in the scanners. They are in the internal directory and end 
in Scanner (EG DGXMLScanner). For DGXMLScanner the revision number the 
code was committed in was 1.54 with message

"Optimized duplicated attributes checking for large number of attributes"

Each of them will have the same message. I have to dash off now, but if 
you have any problems I will happily help you make some patches.

Cheers,

Gareth


-- 
Gareth Reakes, Managing Director      Parthenon Computing
+44-1865-811184                  http://www.parthcomp.com

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org