This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 137264 - CAN-2004-0989 multiple buffer overflows
CAN-2004-0989 multiple buffer overflows
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: libxml2 (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Veillard
Jay Turner
impact=moderate,public=20041026
: Security
Depends On:
Blocks: CVE-2004-0989
  Show dependency treegraph
 
Reported: 2004-10-26 21:51 EDT by Josh Bressers
Modified: 2015-01-07 19:08 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-12 11:41:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Josh Bressers 2004-10-26 21:51:39 EDT
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.
Comment 1 Josh Bressers 2004-10-26 22:05:08 EDT
I've verified that libxml 1 doesn't have these overflows, only libxml2.
Comment 2 Josh Bressers 2004-10-26 22:08:03 EDT
It would seem these fixes are sneaking into upstream CVS.  Dan, I
trust you'll have a patch soon.
Comment 3 Josh Bressers 2004-10-26 22:08:48 EDT
This issue probably also affects RHEL2.1
Comment 4 Daniel Veillard 2004-10-27 05:01:10 EDT
yes very likely ... I commited fixes for 1] and 2] in CVS,
I need to look more closely at 3] for the right way to fix it.
Can you give me an update on how to make those errata releases
once I get the final patches ?

Daniel
Comment 7 Josh Bressers 2004-11-12 11:41:42 EST
An errata has been issued which should help the problem 
described in this bug report. This report is therefore being 
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, 
please follow the link below. You may reopen this bug report 
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2004-615.html

Note You need to log in before you can comment on or make changes to this bug.