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 _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
