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 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.
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 attachment 174350 [details, diff] 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