Bug 137264 - CAN-2004-0989 multiple buffer overflows
Summary: CAN-2004-0989 multiple buffer overflows
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: libxml2 (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: All Linux
Target Milestone: ---
Assignee: Daniel Veillard
QA Contact: Jay Turner
Whiteboard: impact=moderate,public=20041026
Keywords: Security
Depends On:
Blocks: CVE-2004-0989
TreeView+ depends on / blocked
Reported: 2004-10-27 01:51 UTC by Josh Bressers
Modified: 2015-01-08 00:08 UTC (History)
2 users (show)

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

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2004:615 high SHIPPED_LIVE Moderate: libxml2 security update 2004-11-12 05:00:00 UTC

Description Josh Bressers 2004-10-27 01:51:39 UTC
The following information has been posted to bugtraq.



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-27 02:05:08 UTC
I've verified that libxml 1 doesn't have these overflows, only libxml2.

Comment 2 Josh Bressers 2004-10-27 02:08:03 UTC
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-27 02:08:48 UTC
This issue probably also affects RHEL2.1

Comment 4 Daniel Veillard 2004-10-27 09:01:10 UTC
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 ?


Comment 7 Josh Bressers 2004-11-12 16:41:42 UTC
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.


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