Re: [xml] Security fix for libxml2

[Mike Hommey <mh glandium org>]

On Mon, Aug 25, 2008 at 09:47:32PM +0200, Mike Hommey wrote:
> On Sun, Aug 24, 2008 at 10:51:59AM +0200, Daniel Veillard wrote:
> > On Sun, Aug 24, 2008 at 10:15:41AM +0200, Mike Hommey wrote:
> > > On Wed, Aug 20, 2008 at 07:00:51PM +0200, Daniel Veillard wrote:
> > > >   Bad news, when checking against recursive entities expansion problem
> > > > back when it was made official (c.f. the billion laught attack circa
> > > > 2004) I had checked for the normal recursion, but when happening in
> > > > an attribute avlue the resource consumption is way faster and the
> > > > recursion detection in place is not sufficient to catch the problem.
> > > >
> > > >   Basically when this happen within an attribute just checking for
> > > > a recursion depth is not sufficient, and the only good method I could
> > > > find was to count the number of entities replacement taking place while
> > > > parsing a given document, and drop parsing after half a million
> > > > substitution. I think it's a fair default processand what the patches
> > > > below implements for various libxml2 versions, but i can understand that
> > > > in some case that may be problematic. So i intend in the next release
> > > > (2.7.0 hopefully available soon) to add a parser flag removing the
> > > > hardcoded limits (there is also a maximum document depth in place).
> > > >
> > > >   Distributions have been made aware of the problem for a couple of
> > > > weeks and updates should be available soon from normal update channels
> > > > I'm updating SVN with the fix too,
> > >
> > > FWIW, this patch broke binary compatibility with librsvg, which,
> > > foolishly, create xmlEntity objects "by hand" with a
> > > malloc(sizeof(xmlEntity)), in rsvg_entity_decl, which is sets as SAX
> > > entity handler.
> >
> >   Yup:
> >     http://bugzilla.gnome.org/show_bug.cgi?id=549087
> >     https://bugzilla.redhat.com/show_bug.cgi?id=459830
> >
> > I have some backward compatible patches on that last bug
> >
> > > I hope there aren't any more surprises with other libraries or programs.
> >
> >   yeah, it's a serious problem, I made data structure available
> > to help with fast access to the trees, but people have abused it,
> > I hope there isn't too many of those.
> >   I hope librsvg get fixed, because I would really prefer the clean
> > solution in the upcoming 2.7.0 release.
>
> FWIW, strigi is also impacted.
> http://websvn.kde.org/trunk/kdesupport/strigi/src/streamanalyzer/fieldpropertiesdb.cpp?view=markup
> (look for "new xmlEntity")

And many others, as reported on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496125 :

liferea 1.4.16b has this:

  src/xml.c:                    entity = (xmlEntityPtr)g_new0 (xmlEntity, 1);

PHP 5.2.6 has this:

  ext/dom/dom_iterators.c:61:      ret = (xmlEntityPtr) xmlMalloc(sizeof(xmlEntity));
  ext/dom/dom_iterators.c:62:      memset(ret, 0, sizeof(xmlEntity));

QT 4.4.0 has this (with an instructive comment in front of it):

  src/3rdparty/webkit/WebCore/dom/XMLTokenizer.cpp:static xmlEntity sharedXHTMLEntity = {

(Note that for the latter, there is also, at least in upstream webkit:
#if LIBXML_VERSION >= 20627
    // xmlEntity gained an extra member in 2.6.27.
    1
#endif

Which is quite ugly actually.

Anyways, I'm afraid it means you're doomed.

Mike