Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 240496 (CVE-2008-4482) - dev-libs/xerces-c <3.0.0-r1 maxOccurs XML schema DoS (CVE-2008-4482)
Summary: dev-libs/xerces-c <3.0.0-r1 maxOccurs XML schema DoS (CVE-2008-4482)
Status: RESOLVED FIXED
Alias: CVE-2008-4482
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High minor (vote)
Assignee: Gentoo Security
URL: http://issues.apache.org/jira/browse/...
Whiteboard: B3 [glsa]
Keywords:
Depends on: 242218
Blocks: 241500
  Show dependency tree
 
Reported: 2008-10-08 12:12 UTC by Stefan Behte (RETIRED)
Modified: 2009-03-09 14:01 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
test log from src_test phase (test-results.log,4.85 KB, text/plain)
2008-10-15 17:41 UTC, Ferris McCormick (RETIRED)
no flags Details
Minor test-case informativeness enhancement patch (testInform.patch,3.83 KB, patch)
2008-12-05 19:33 UTC, Kent Fredric (IRC: kent\n) (RETIRED)
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Behte (RETIRED) gentoo-dev Security 2008-10-08 12:12:50 UTC
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.
Comment 1 Tiziano Müller (RETIRED) gentoo-dev 2008-10-15 10:32:39 UTC
3.0.0 is now in the tree
Comment 2 Stefan Behte (RETIRED) gentoo-dev Security 2008-10-15 13:22:48 UTC
Thanks! Arches, please test and mark stable.
Comment 3 Ferris McCormick (RETIRED) gentoo-dev 2008-10-15 15:31:03 UTC
(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. :)
Comment 4 Stefan Behte (RETIRED) gentoo-dev Security 2008-10-15 15:32:54 UTC
I thought Tiziano had done that, I don't have commit rights.
Comment 5 Christian Hoffmann (RETIRED) gentoo-dev 2008-10-15 15:45:02 UTC
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].
Comment 6 Ferris McCormick (RETIRED) gentoo-dev 2008-10-15 17:41:33 UTC
Created attachment 168592 [details]
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.
Comment 7 Mark Loeser (RETIRED) gentoo-dev 2008-10-25 17:50:43 UTC
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.
Comment 8 Ferris McCormick (RETIRED) gentoo-dev 2008-10-25 18:46:37 UTC
(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.
Comment 9 Ferris McCormick (RETIRED) gentoo-dev 2008-11-11 22:11:43 UTC
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.
Comment 10 Robert Buchholz (RETIRED) gentoo-dev 2008-11-11 22:46:04 UTC
Arches, please test and mark stable:
=dev-libs/xerces-c-3.0.0-r1
Target keywords : "alpha amd64 ppc ppc64 sparc x86"
Comment 11 Ferris McCormick (RETIRED) gentoo-dev 2008-11-11 23:54:31 UTC
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.
Comment 12 Ferris McCormick (RETIRED) gentoo-dev 2008-11-12 00:43:52 UTC
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.
Comment 13 Mark Loeser (RETIRED) gentoo-dev 2008-11-12 01:19:56 UTC
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.
Comment 14 Robert Buchholz (RETIRED) gentoo-dev 2008-11-12 04:35:14 UTC
removing arches until then. please give a feedback, we're targeting nov. 16 to re-add arches for stabling of both ebuilds.
Comment 15 Tobias Heinlein (RETIRED) gentoo-dev 2008-11-22 18:16:41 UTC
ping, any news here?
Comment 16 Mark Loeser (RETIRED) gentoo-dev 2008-11-23 22:26:53 UTC
Just started the stablereq process on the other bug since I haven't received anything stating it doesn't work.
Comment 17 Mark Loeser (RETIRED) gentoo-dev 2008-11-26 21:23:56 UTC
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
Comment 18 Ferris McCormick (RETIRED) gentoo-dev 2008-11-26 21:54:08 UTC
(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.
Comment 19 Robert Buchholz (RETIRED) gentoo-dev 2008-11-26 23:24:44 UTC
(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.
Comment 20 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2008-12-05 19:31:12 UTC
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 ) 
Comment 21 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2008-12-05 19:33:23 UTC
Created attachment 174350 [details, diff]
Minor test-case informativeness enhancement patch
Comment 22 Mark Loeser (RETIRED) gentoo-dev 2008-12-09 02:28:06 UTC
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
Comment 23 Ferris McCormick (RETIRED) gentoo-dev 2008-12-09 06:45:04 UTC
(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")
Comment 24 Ferris McCormick (RETIRED) gentoo-dev 2008-12-09 07:04:00 UTC
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.
Comment 25 Brent Baude (RETIRED) gentoo-dev 2008-12-09 15:53:22 UTC
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.
Comment 26 Ferris McCormick (RETIRED) gentoo-dev 2008-12-09 18:34:42 UTC
Sparc stable for xerces-c-3.0.0-r1 and xalan-c-1.11.0_pre705082.  Comments 22, 23, 24 above for details.
Comment 27 Tobias Klausmann (RETIRED) gentoo-dev 2008-12-11 22:20:06 UTC
I ran into the same testing troubles as ranger (comment #25), fixed them the same way and stabilized xerces-c as requested.
Comment 28 Tobias Scherbaum (RETIRED) gentoo-dev 2008-12-13 13:30:34 UTC
ppc stable
Comment 29 Markus Meier gentoo-dev 2008-12-14 11:16:22 UTC
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/
Comment 30 Markus Meier gentoo-dev 2008-12-14 12:44:02 UTC
amd64/x86 stable, all arches done.
Comment 31 Tobias Heinlein (RETIRED) gentoo-dev 2008-12-15 14:01:03 UTC
Denial of Service is 3, not 4. Updating whiteboard.
Comment 32 Tobias Heinlein (RETIRED) gentoo-dev 2008-12-15 14:01:29 UTC
Ready for vote, I vote YES.
Comment 33 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2009-01-11 17:40:18 UTC
Yes too, filling request.
Comment 34 Robert Buchholz (RETIRED) gentoo-dev 2009-03-09 14:01:42 UTC
GLSA 200903-19