The following information has been posted to bugtraq.

http://www.securityfocus.com/archive/1/379383/2004-10-24/2004-10-30/0

Details:

1]The vulnerable code occurs in the file nanoftp.c in function
xmlNanoFTPScanURL() around line 360:

    while (cur[0] != ']')
        buf[indx++] = *cur++;
             

buf is the stack buffer, and cur is the URL we control.  What's funny
here, is that in other areas of the code the same mistake is avoided,
we have this:

    while ((cur[0] != ']') && (indx < XML_NANO_MAX_URLBUF-1))
        buf[indx++] = *cur++;

Which occurs in a similar function to the one called above.
  

2]The vulnerable code occurs in the file nanoftp.c in function
xmlNanoFTPScanProxy() around line 610:

    while (cur[0] != ']')
        buf[indx++] = *cur++;
             

buf is the stack buffer, and cur is the URL we control.


3]There are two different functions, with three different code
sections each containing two overflows.  However I'd classify this as
two distinct bugs, not six, as two of the bugs are conditionally
compiled in only if two others are not.  The first two occur in the
file nanoftp.c, lines 1110-1120, in the function xmlNanoFTPConnect().
 The function getaddrinfo() is called to resolve a hostname, the
returned info is then copied into a heap buffer in a call to memcpy().
 The copy length is taken from the DNS reply, rather than using the
size of the destination structure.  The second set occur in
nanohttp.c, lines 1070-1080, in the function xmlNanoHTTPConnectHost().
 Data from getaddrinfo() is again copied incorrectly, this time into a
local stack buffer.  The third set of overflows occurs in nanohttp.c,
lines 1145-1155, in the function xmlNanoHTTPConnectHost().  This time,
gethostbyname() is called, and data is again memcpy()'d into a local
stack buffer using the DNS length instead of destination structure size.