Bug 139090 - CAN-2004-0110 multiple buffer overflows (CAN-2004-0989)
Summary: CAN-2004-0110 multiple buffer overflows (CAN-2004-0989)
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: libxml
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Veillard
QA Contact: Jay Turner
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)

Clone Of:
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.


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.


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

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 
   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 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

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.


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