Bug 139090
| Summary: | CAN-2004-0110 multiple buffer overflows (CAN-2004-0989) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Josh Bressers <bressers> |
| Component: | libxml | Assignee: | Daniel Veillard <veillard> |
| Status: | CLOSED ERRATA | QA Contact: | Jay Turner <jturner> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.0 | CC: | michal, srevivo |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | impact=moderate,public=20040824 | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-12-16 20:52:08 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 139406 | ||
| Bug Blocks: | 430644, 430645 | ||
|
Description
Josh Bressers
2004-11-12 21:08:43 UTC
We need to make sure this gets fixed in RHEL4 as well. For RHEL-4 I intend to get 2.6.16 pushed to it anyway. Daniel 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. Testing comment. 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 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.
Scratch the last comment. I cannot add. Obviously not enough fingers. 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 |