#485 memory leak in poolGrow

Test Required
open-fixed
Karl Waclawek
None
5
2 days ago
2010-02-25
Tim Boddy
No

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->realloc_fcn(pool->blocks,
(offsetof(BLOCK, s)
+ blockSize * sizeof(XML_Char)));
if (pool->blocks == NULL)
return XML_FALSE;
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 realloc_fcn 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.

Discussion

  • Karl Waclawek
    Karl Waclawek
    2010-02-25

    • milestone: --> Test Required
    • assigned_to: nobody --> kwaclaw
    • status: open --> open-fixed
     
  • Karl Waclawek
    Karl Waclawek
    2010-02-25

    Fixed in xmlparse.ca rev. 1.167.