Bug 139090 - CAN-2004-0110 multiple buffer overflows (CAN-2004-0989)
CAN-2004-0110 multiple buffer overflows (CAN-2004-0989)
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: libxml (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Veillard
Jay Turner
impact=moderate,public=20040824
: 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:
Environment:
Last Closed: 2004-12-16 15:52:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

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

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0110
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0989

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.

Daniel
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
updates.

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 
pushed 
   libxml-1.8.17-9.2 into dist-3.0E-errata-candidate
and
   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

Daniel
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
fingers.
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.

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

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