** Please note that this issue is CONFIDENTIAL and no information should be disclosed until it is made public, see "Whiteboard" for a date ** Josh Bressers writes: Andreas Solberg discovered a denial of service flaw in libxml2. This flaw leads to recursive evaluation of entities, the result being an exhaustion of memory and CPU usage.
Created attachment 162368 [details, diff] libxml2-2.6.32-CVE-2008-3281.patch
Created attachment 162398 [details] libxml2-2.6.32-r1.ebuild don't know what the +/- 3 trick vs +/- 1 is, but builds fine and doesn't seem to cause problems to apps linked to it.
Arch Security Liaisons, please test the attached ebuild and report it stable on this bug. Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86" CC'ing current Liaisons: alpha : yoswink, armin76 amd64 : keytoaster, tester hppa : jer ppc : dertobi123 ppc64 : corsair sparc : fmccor x86 : maekke, armin76
HPPA is OK.
looks good on ppc64
Looks good on sparc for stable, does fine with USE=test FEATURES=test (One test expected 11 failures but got 10; I'm not going to worry about that.)
alpha/ia64 looks okay
looks good on amd64/x86.
Created attachment 162889 [details, diff] libxml2-2.6.32-CVE-2008-3281.patch The prior patch is incomplete, upstream proposes this new version.
Furthermore, the embargo deadline has been extended to Aug. 20. Arch liaisons, please test once more with the new patch, and same ebuild.
Tests are all good on sparc.
(In reply to comment #10) > Furthermore, the embargo deadline has been extended to Aug. 20. > > Arch liaisons, please test once more with the new patch, and same ebuild. > still looks good for ppc
Still looks ok for alpha
looks good on ppc64, too.
Still looks good on ia64/x86
HPPA is still OK.
Fine on amd64.
now public, please commit.
Ebuild is in tree now. CCing remaining architectures
This actually breaks gnome-base/gdm greeter (these should be themes in XML files) loading and renders gdm completely broken... Works with 2.6.32-r0, breaks with 2.6.32-r1 that I committed
Adding the bug for the gdm issue as a dependency
I have package.masked libxml-2.6.32-r1, that includes the security patch, until the gdm issue is sorted out. gdm not working is a worse DoS than a chance of the other possible DoS that the patch is supposed to fix.
Back to [upstream] waiting for a better working fix then...
Shouldn't the fix have included a SONAME change due to the addition of members to structures passed between the library and its callers?
(In reply to comment #24) > Shouldn't the fix have included a SONAME change due to the addition of members > to structures passed between the library and its callers? Probably yes, but apparently noone thought of this / has seen this. Some updates (from oss-sec), Nico Golde pointed to [1] which says that rebuilding the affected packages (only librsvg known until now) should solve this. Not that nice for a security update though... He also pointed to [2] which has a different patch which avoids breaking compatibility of the public headers. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496125#79 [2] https://bugzilla.redhat.com/show_bug.cgi?id=459830 (currently down)
(In reply to comment #25) > (In reply to comment #24) > Some updates (from oss-sec), Nico Golde pointed to [1] which says that > rebuilding the affected packages (only librsvg known until now) should solve > this. Not that nice for a security update though... Ok, according to oss-sec, some more packages are affected: gnome-base/librsvg (as already noted) app-misc/strigi net-news/liferea (1.4.16b has been tested) dev-lang/php USE=xml (5.2.6 has been tested) x11-libs/qt-webkit (4.4.0 has been tested) So, requring zero-change version bumps of these packages and putting DEPENDs as necessary does not sound like a too good idea, maybe we should really wait for the new patch to be tested appropriately.
(In reply to comment #26) > So, requring zero-change version bumps of these packages and putting DEPENDs as > necessary does not sound like a too good idea, maybe we should really wait for > the new patch to be tested appropriately. Yes, I will not allow an ABI break without soname bump in anyhow - security or not, ABI stability is important in GNOME world. Was a mistake I didn't notice that the patch breaks ABI before putting it in.
Mart, what's your plan to resolve this issue?
It turns out upstream restored the ABI before release of 2.7.0 and there was some blindness from my part by not noticing this in SVN or release changes, and the fact not being mentioned in any of the upstream bugs I monitored or looked at. libxml2-2.7.1 is now in the tree and includes an ABI compatible fix for this security bug and also security bug 237806. Arches, please give it a good spin and stable. A list of packages that shouldn't break when compiled against libxml2-2.6.32 and ran against libxml2-2.7.1 is in comment #26, plus check you can still log in via gdm-2.20.x after making sure it restarted.
Stable for HPPA.
Sparc stable, tests look good.
ppc64 stable
alpha/ia64/x86 stable
amd64 stable
ppc stable
GLSA request filed.
Do I see this right that the issue should be fixed in libxml-2.7.1? I still have it, just try download http://tmp.cweiske.de/manual.xml and run "xmllint manual.xml"
(In reply to comment #37) > Do I see this right that the issue should be fixed in libxml-2.7.1? I still > have it, just try download http://tmp.cweiske.de/manual.xml and run "xmllint > manual.xml" Same here. I see you've already reported it upstream: http://bugzilla.gnome.org/show_bug.cgi?id=554660
Back to [upstream] for the second time then (I can reproduce the issue as well, btw).
(In reply to comment #37) > Do I see this right that the issue should be fixed in libxml-2.7.1? I still > have it, just try download http://tmp.cweiske.de/manual.xml and run "xmllint > manual.xml" Let's handle this new issue in bug 239346, back to [glsa] for this issue.
GLSA 200812-06
