Bugzilla Bug 240496

CVE-2008-4482 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-4482):
  The XML parser in Xerces-C++ before 3.0.0 allows context-dependent
  attackers to cause a denial of service (stack consumption and crash)
  via an XML schema definition with a large maxOccurs value, which
  triggers excessive memory consumption during validation of an XML
  file.

3.0.0 is now in the tree

Thanks! Arches, please test and mark stable.

(In reply to comment #2)
> Thanks! Arches, please test and mark stable.
> 
Sure, once you put the source xerces-c-3.0.0.tar.gz somewhere. :)

I thought Tiziano had done that, I don't have commit rights.

Looks like apache mirror structure has been reorganized in case of xerces.
New SRC_URI should be e.g.
http://apache.nedmirror.nl/xerces/c/3/sources/xerces-c-3.0.0.tar.gz (I'm not
fixing it myself because there is another major issue).

=dev-libs/xerces-c-3.0.0 cannot go stable (as darksiide pointed out on IRC), it
is EAPI=2.
Maintainers, could you backport the fix?

Removing arches for now, back to [ebuild].

Created an attachment (id=168592) [edit]
test log from src_test phase

For completeness, I'll mention that the tests fail, apparently because the
package expects all test results to be part of the test-results.log, but they
are not.  On both sparc and on amd64, I get the attached test-results.log, and
it claims all tests pass.  However, the supplied expected output
(xerces-c-3.0.0/scripts/sanityTest_ExpectedResult.log) contains the output from
the tests (and is 1213 lines long).  Thus, even if we didn't have the EAPI=2
issue, we couldn't mark this stable because FEATURES=test fails spectacularly.

I think the problem is with how the tests are run.  It looks like they run
successfully, but I don't know where their output goes.  Wherever it is,
results are identical on sparc and amd64.

Added a new ebuild (3.0.0-r1) which is EAPI=0 and I believe I fixed the tests. 
Please test and let me know.  There's one series of tests that *might* fail.

(In reply to comment #7)
> Added a new ebuild (3.0.0-r1) which is EAPI=0 and I believe I fixed the tests. 
> Please test and let me know.  There's one series of tests that *might* fail.
> 

It shows a failure, thus, which might be a glibc problem:
======================
*** glibc detected ***
/var/tmp/portage/dev-libs/xerces-c-3.0.0-r1/work/xerces-c-3.0.0/tests/.libs/lt-ThreadTest:
double free or corruption (!prev): 0x71d189a0 ***
*** glibc detected *** *** glibc detected ***
/var/tmp/portage/dev-libs/xerces-c-3.0.0-r1/work/xerces-c-3.0.0/tests/.libs/lt-ThreadTest:
double free or corruption (!prev): 0x*** glibc detected ***
/var/tmp/portage/dev-libs/xerces-c-3.0.0-r1/work/xerces-c-3.0.0/tests/.libs/lt-ThreadTest:
double free or corruption (!prev): 0x72110aa0 ***
diff test-results.log ./scripts/sanityTest_ExpectedResult.log
1169,1170c1169,1181
< 123Test Run Successfully
< 45678910111213Test Run Successfully
---
> 1Test Run Successfully
> 2Test Run Successfully
> 3Test Run Successfully
> 4Test Run Successfully
> 5Test Run Successfully
> 6Test Run Successfully
> 7Test Run Successfully
> 8Test Run Successfully
> 9Test Run Successfully
> 10Test Run Successfully
> 11Test Run Successfully
> 12Test Run Successfully
> 13Test Run Successfully
make: *** [check] Error 1
==========================

As for the actual output, the
123Test Run Successfully
is supposed to be
1Test ...
2Test ...

================
I am using
sys-libs/glibc-2.6.1 on this system.

At Mark's (Halcy0n's) request, I ran the tests with FEATURES='test -sandbox',
and with '-sandbox' everything now runs correctly for xerces-c-3.0.0-r1.  Based
on that, since this is a security bug, sparc is ready to go stable when you
wish.

Arches, please test and mark stable:
=dev-libs/xerces-c-3.0.0-r1
Target keywords : "alpha amd64 ppc ppc64 sparc x86"

Sparc stable, everything now tests successfully (with FEATURES='-sandbox
test').  Problems were with the tests, not with the package, and thanks to
Halcy0n for the assistance.

Reverting sparc to ~sparc temporarily, awaiting resolution of some apparent
coordination problems with xalan-c.  I'll take care of everything at once when
we are in sync.

xalan-c doesn't compile with xerces-c-3.  I have added a new version to the
tree, but I would like for it to sit for a few days before asking for arches to
stable.

removing arches until then. please give a feedback, we're targeting nov. 16 to
re-add arches for stabling of both ebuilds.

ping, any news here?

Just started the stablereq process on the other bug since I haven't received
anything stating it doesn't work.

Maybe we should add the arches here as well to get some action happening on bug
#242218  We are still waiting on amd64 and x86 there

(In reply to comment #17)
> Maybe we should add the arches here as well to get some action happening on bug
> #242218  We are still waiting on amd64 and x86 there
> 

Sparc is ready when you are.

(In reply to comment #17)
> Maybe we should add the arches here as well to get some action happening on bug
> #242218  We are still waiting on amd64 and x86 there

Feel free to CC arches on this bug, but please state the exact stabling targets
because both this and the bug 242218 are not fun to read through.

More affirmation the tests failing appears to be a sandboxing issue. 

I Upgraded to sandbox 1.3.1 and the glibc warnings disappeared, but the tests
are still segfaulting mysteriously. I improved the Perl script  that runs the
tests so that they're a little more informative as to what is going on, so now,
under sandbox, this happens: 

( With a bit of random variation, sandbox doesn't look like it wants to crash
in consistent ways )

1Test Run Successfully
2Test Run Successfully
3Test Run Successfully
4Test Run Successfully
5 ThreadTest -parser=dom -v=always -quiet -threads 10 -time 20 personal.xml
Exited With State 11
6 ThreadTest -parser=sax2 -v=always -quiet -threads 10 -time 20 personal.xml
Exited With State 11
7 ThreadTest -parser=sax -gc -v=always -quiet -threads 10 -time 20 personal.xml
Exited With State 11
8 ThreadTest -parser=dom -gc -v=always -quiet -threads 10 -time 20 personal.xml
Exited With State 11
9 ThreadTest -parser=sax2 -gc -v=always -quiet -threads 10 -time 20
personal.xml Exited With State 11
10 ThreadTest -parser=sax -n -s -f -v=always -quiet -threads 10 -time 20
personal-schema.xml Exited With State 11
11 ThreadTest -parser=dom -n -s -f -v=always -quiet -threads 10 -time 20
personal-schema.xml Exited With State 11
12Test Run Successfully
13Test Run Successfully
14Test Run Successfully
15Test Run Successfully

And without sandbox, this happens: 

1Test Run Successfully
2Test Run Successfully
3Test Run Successfully
4Test Run Successfully
5Test Run Successfully
6Test Run Successfully
7Test Run Successfully
8Test Run Successfully
9Test Run Successfully
10Test Run Successfully
11Test Run Successfully
12Test Run Successfully
13Test Run Successfully
14Test Run Successfully
15Test Run Successfully

Which makes the diff of fails at the end of it all more useful. 

( I only changed the part that was affected by sandbox crashes ) 

Created an attachment (id=174350) [edit]
Minor test-case informativeness enhancement patch

Arche, please mark the following stable:

amd64, sparc, x86: dev-libs/xalan-c-1.11.0_pre705082
everyone: dev-libs/xerces-c-3.0.0-r1

(In reply to comment #22)
> Arche, please mark the following stable:
> 
> amd64, sparc, x86: dev-libs/xalan-c-1.11.0_pre705082
> everyone: dev-libs/xerces-c-3.0.0-r1
> 

sparc went stable on dev-libs/xalan-c-1.11.0_pre705082 on 23 November.  sparc
tried to go stable on dev-libs/xerces-c-3.0.0-r1 on 11 November but reverted it
because it needed to wait for xalan.  So, now sparc can go stable on xerces-c
again if you like (tests with it run fine thanks to your help), but we can't do
anything on xalan-c.  Please advise --- perhaps you meant ppc instead of sparc?
(xalan-c currently is "~amd64 ~ppc sparc ~x86")

Oh, because this is a security bug, I did build xalan-c with xerces-c-3.0.0-r1
so I know that combination is good on sparc.

ppc64 done.

I talked to halcy0n about a failure I saw with ppc64 where I had -threads and
yet threaded tests were being executed (which == fail).  I enabled threads and
bumped into the segfault that other arches saw with sandbox.  So the
combination of threads/-sandbox resulted in successful compilation and test.

Sparc stable for xerces-c-3.0.0-r1 and xalan-c-1.11.0_pre705082.  Comments 22,
23, 24 above for details.

I ran into the same testing troubles as ranger (comment #25), fixed them the
same way and stabilized xerces-c as requested.

ppc stable

looks good on amd64/x86, minor ebuild issue:
rm: cannot remove `samples/data': Is a directory
rm: cannot remove `samples/src': Is a directory
>>> Completed installing xerces-c-3.0.0-r1 into /var/tmp/portage/dev-libs/xerces-c-3.0.0-r1/image/

amd64/x86 stable, all arches done.

Denial of Service is 3, not 4. Updating whiteboard.

Ready for vote, I vote YES.

Yes too, filling request.

GLSA 200903-19