Bug 139090 - CAN-2004-0110 multiple buffer overflows (CAN-2004-0989)
Summary: CAN-2004-0110 multiple buffer overflows (CAN-2004-0989)
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: libxml
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Veillard
QA Contact: Jay Turner
URL:
Whiteboard: impact=moderate,public=20040824
Keywords: Security
Depends On: 139406
Blocks: CVE-2004-0110 CVE-2004-0989
TreeView+ depends on / blocked
 
Reported: 2004-11-12 21:08 UTC by Josh Bressers
Modified: 2015-01-08 00:08 UTC (History)
2 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2004-12-16 20:52:08 UTC


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 05:00:00 UTC

Description Josh Bressers 2004-11-12 21:08:43 UTC
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 21:10:33 UTC
We need to make sure this gets fixed in RHEL4 as well.

Comment 2 Daniel Veillard 2004-11-12 21:59:20 UTC
For RHEL-4 I intend to get 2.6.16 pushed to it anyway.

Daniel

Comment 3 Josh Bressers 2004-11-12 22:20:30 UTC
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 22:33:03 UTC
Testing comment.

Comment 5 Daniel Veillard 2004-11-17 15:50:52 UTC
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 19:00:32 UTC
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 19:03:25 UTC
Scratch the last comment.  I cannot add.  Obviously not enough
fingers.

Comment 8 Josh Bressers 2004-12-16 20:52:08 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.

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.