Bugzilla Bug 234099

** 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 an attachment (id=162368) [details]
libxml2-2.6.32-CVE-2008-3281.patch

Created an attachment (id=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 an attachment (id=162889) [details]
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