Bug 139090 - CAN-2004-0110 multiple buffer overflows (CAN-2004-0989)
CAN-2004-0110 multiple buffer overflows (CAN-2004-0989)
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: libxml (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Veillard
Jay Turner
: Security
Depends On: 139406
Blocks: CVE-2004-0110 CVE-2004-0989
  Show dependency treegraph
Reported: 2004-11-12 16:08 EST 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:
Last Closed: 2004-12-16 15:52:08 EST
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:650 normal SHIPPED_LIVE Moderate: libxml security update 2004-12-16 00:00:00 EST

  None (edit)
Description Josh Bressers 2004-11-12 16:08:43 EST
We missed these buffer overflows in libxml, which we fixed in libxml2.


These issues also affect RHEL2.1
Comment 1 Josh Bressers 2004-11-12 16:10:33 EST
We need to make sure this gets fixed in RHEL4 as well.
Comment 2 Daniel Veillard 2004-11-12 16:59:20 EST
For RHEL-4 I intend to get 2.6.16 pushed to it anyway.

Comment 3 Josh Bressers 2004-11-12 17:20:30 EST
To clarify this (I've confused a few people).

We ship libxml2 and libxml1.  We applied these fixes to libxml2 and released

We did not apply these to libxml1.
Comment 4 Josh Bressers 2004-11-12 17:33:03 EST
Testing comment.
Comment 5 Daniel Veillard 2004-11-17 10:50:52 EST
Okidoc, I made a patch CAN-2004-0110.patch which should fix both 
problems in the nanoftp.c and nanohttp.c of libxml-1.8.17. 
Since It also applies directly to -1.8.14, as a result I 
   libxml-1.8.17-9.2 into dist-3.0E-errata-candidate
   libxml-1.8.14-3   into dist-2.1AS-errata-candidate

Concerning RHEL-4, libxml1 should not be part of it, it ended up there
before due to packaging errors, see #139406, so the full resolution
of this bug also depens on it

Comment 6 Michal Jaegermann 2004-11-20 14:00:32 EST
In libxml2-2.6.16-{2,3}.src.rpm, released as Fedora updates, in
nanoftp.c there is the following code in two places:

    else {
        indx = 0;
        buf[indx] = 0;
        while ((*cur != 0) && (indx < XML_NANO_MAX_URLBUF-1))
            buf[indx++] = *cur++;
        buf[indx] = 0;
        ctxt->path = xmlMemStrdup(buf);

In other words after a 'while' loop 'indx' may be equal to
XML_NANO_MAX_URLBUF and 'buf[indx] = 0' writes past 'buf' boundaries
as it was declared 'char buf[XML_NANO_MAX_URLBUF]'.

There is also a bunch of other assignments, always 'buf[indx] = 0'
after other 'while' loops guarded by conditions of
' ... (indx < XML_NANO_MAX_URLBUF-1)' type and where 'indx' is
incremented after that.

It seems that the simplest solution is to change the last declaration
to 'char buf[XML_NANO_MAX_URLBUF + 1]' or change a guard to
'(indx < XML_NANO_MAX_URLBUF-2)'.

As far as I can see at least 'xmlNanoHTTPScanURL()' from nanohttp.c
has the same issue.
Comment 7 Michal Jaegermann 2004-11-20 14:03:25 EST
Scratch the last comment.  I cannot add.  Obviously not enough
Comment 8 Josh Bressers 2004-12-16 15:52:08 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.


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