Bug 152828

A quote from Fedora Update Notification FEDORA-2004-353:

Multiple buffer overflow bugs have been found libxml2 versions prior to
2.6.14.  If an attacker can trick a user into passing a specially crafted
FTP URL or FTP proxy URL to libxml2, it could be possible to execute
arbitrary code.  Additionally, if an attacker can return a specially
crafted DNS request to libxml, it is possible to execute arbitrary code.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-0989 to this issue.

References:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137266
http://www.securityfocus.com/archive/1/379383/2004-10-24/2004-10-30/0
upstream release 2.6.15 see http://xmlsoft.org/news.html



------- Additional Comments From michal 2004-10-28 12:43:53 ----

Created an attachment (id=903)
patch for problems in libxml2-2.4.19

Looking through details of 
http://www.securityfocus.com/archive/1/379383/2004-10-24/2004-10-30/0
problems raised there in points 1) and 2) are already fixed in released
libxml2-2.4.19-6.legacy.

This patch adds checks to guard against overflows from point 3) and is
similar in principle to what can be found in libxml2-2.6.15

While FC2 got libxml2-2.6.15-2 as an erratum for FC3t libxml2-2.6.14-2
showed up in this role.  Strange but true.



------- Additional Comments From rob.myers.edu 2004-11-04 14:19:21 ----

also, we need to check to make sure that
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137499
doesn't affect these updates, too.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Here are updated libxml2 packages to QA for rh73, rh90, and fc1:
  
- - CAN-2004-0989 should be fixed
- - should compile under mach
 
changelogs:
 
rh73:
* Thu Nov 04 2004 Rob Myers <rob.myers.edu> 2.4.19-7.legacy
- - apply patch for CAN-2004-0989 (FL #2207)
 
rh9:
* Thu Nov 04 2004 Rob Myers <rob.myers.edu> 2.5.4-3.rh9.1.legacy
- - apply patch for CAN-2004-0989 (FL #2207)
- - add BuildRequires: libtool, zlib-devel
 
fc1:
* Thu Nov 04 2004 Rob Myers <rob.myers.edu> 2.6.6-3.1.legacy
- - apply patches for CAN-2004-0989 (FL #2207)
- - add BuildRequires: zlib-devel
  
sha1sums:
 
rh73:
526f83b7f5bab691610257ad75c9cda2d360372f  libxml2-2.4.19-7.legacy.i386.rpm
f9e482e80a0f80890dfd904e520178f72abbabb8  libxml2-2.4.19-7.legacy.src.rpm
c886647981ec80223027dd0472a43f54b7aba4d4  libxml2-devel-2.4.19-7.legacy.i386.rpm
299a71586fe369e1602177e7e36fea9fca0cd9f3  libxml2-python-2.4.19-7.legacy.i386.rpm
 
rh9:
a0ced6852404988309c11fbc66601e1f00c685c5  libxml2-2.5.4-3.rh9.1.legacy.i386.rpm
543a79994c053a56598e7a69a8056ec527178766  libxml2-2.5.4-3.rh9.1.legacy.src.rpm
8b70c6acfd8f26fe21fb1a895083ed5d3b82b9f9 
libxml2-debuginfo-2.5.4-3.rh9.1.legacy.i386.rpm
4fd6cb717a2ddc3315c313daf1517f395c37dea7 
libxml2-devel-2.5.4-3.rh9.1.legacy.i386.rpm
1c1270fea87a68a4dfe8292de45bee74bb32e716 
libxml2-python-2.5.4-3.rh9.1.legacy.i386.rpm
 
fc1:
ba81e0ddaadcda270770e6161fd4aa2dfc51e73c  libxml2-2.6.6-3.1.legacy.i386.rpm
6b22a97268045b74308debac5a8e3121ccd5868f  libxml2-2.6.6-3.1.legacy.src.rpm
7302ece5b56edd8e829c1068997aa481294e1771 
libxml2-debuginfo-2.6.6-3.1.legacy.i386.rpm
15cf6e1cc2bc83a3b4673ca2f47e7172669d3996  libxml2-devel-2.6.6-3.1.legacy.i386.rpm
4eb3a653192cb0918556682afa3439d533b7c1ae  libxml2-python-2.6.6-3.1.legacy.i386.rpm
  
files:
 
rh73:
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml2-2.4.19-7.legacy.src.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml2-2.4.19-7.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml2-devel-2.4.19-7.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml2-python-2.4.19-7.legacy.i386.rpm
 
rh9:
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml2-2.5.4-3.rh9.1.legacy.src.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml2-2.5.4-3.rh9.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml2-debuginfo-2.5.4-3.rh9.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml2-devel-2.5.4-3.rh9.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml2-python-2.5.4-3.rh9.1.legacy.i386.rpm
 
fc1:
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml2-2.6.6-3.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml2-2.6.6-3.1.legacy.src.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml2-debuginfo-2.6.6-3.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml2-devel-2.6.6-3.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml2-python-2.6.6-3.1.legacy.i386.rpm
 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
 
iD8DBQFBisXdtU2XAt1OWnsRAqiSAKC39kCUVZraQFZBRupg1bnDqrwKDwCg0m0y
vFBmChfMpbhjvlINkjx/ZM8=
=/lh6
-----END PGP SIGNATURE-----




------- Additional Comments From dom 2004-11-15 14:19:21 ----

Red Hat advisory: https://rhn.redhat.com/errata/RHSA-2004-615.html



------- Additional Comments From josh.kayse.edu 2004-11-16 04:41:31 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I did QA on the FC1 package:

6b22a97268045b74308debac5a8e3121ccd5868f  libxml2-2.6.6-3.1.legacy.src.rpm

- - source identical to the previous release
- - patches look good
- - spec file looks good
- - builds cleanly
- - installs fine
- - runs fine

+ PUBLISH

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBmhD7wnUFCSDmt7ERAp8jAJ48GyfPvXmhnK9r1B77rLfDSgGZhgCgj/HZ
ZtM55J31ju8MRu2rrWW9Vkc=
=g0Ri
-----END PGP SIGNATURE-----




------- Additional Comments From marcdeslauriers 2004-11-20 05:57:55 ----

We must make libxml packages to, as it's not just libxml2 that's vulnerable.

See:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139090



------- Additional Comments From michal 2004-11-20 10:22:13 ----

Created an attachment (id=928)
libxml--1.8.17 security patch copied from Fedora updates

> We must make libxml packages to ...

Indded, you are right.	But 'CAN-2004-0110.patch' from libxml updates for
FC2 and FC3 applies directly to othere corresponding packages.	To makes
references easier it is attached to this report to.

OTOH 'libxml10', which is present in at least rh7.3, is not affected by
the issue as the code in question is simply absent from there.



------- Additional Comments From rob.myers.edu 2004-11-24 07:42:12 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Here are updated libxml packages to QA for rh73, rh90, and fc1:
  
- - CAN-2004-0110 and CAN-2004-0989 should be fixed
 
- - should build properly in mach
 
- - all from the same source, please test well since this includes:
  for rh73: an explicit epoch addition and a spec file clean up
  for rh9: an explicit epoch addition
 
changelogs:
 
rh73:
* Wed Nov 24 2004 Rob Myers <rob.myers.edu> 1.8.17-9.0.7.3.1.legacy
- - apply patch for CAN-2004-0110, CAN-2004-0989 (FL #2207)
- - added BuildRequires: zlib-devel
- - rebuilt for rh73
 
rh9:
* Wed Nov 24 2004 Rob Myers <rob.myers.edu> 1.8.17-9.0.9.1.legacy
- - apply patch for CAN-2004-0110, CAN-2004-0989 (FL #2207)
- - added BuildRequires: zlib-devel
- - rebuilt for rh9
 
fc1:
* Wed Nov 24 2004 Rob Myers <rob.myers.edu> 1.8.17-9.1.legacy
- - apply patch for CAN-2004-0110, CAN-2004-0989 (FL #2207)
- - added BuildRequires: zlib-devel
- - rebuilt for fc1
  
sha1sums:
 
rh73:
936cec52d7a64c12e10035a64e634dd3064a1797  libxml-1.8.17-9.0.7.3.1.legacy.i386.rpm
1ea07f6ce79a97c09292080024e04968f324f0cf  libxml-1.8.17-9.0.7.3.1.legacy.src.rpm
e10215dd8fd7429b0c40b06c19f815f51de26afe 
libxml-devel-1.8.17-9.0.7.3.1.legacy.i386.rpm
 
rh9:
74c55e8dc0213fd6e00fed94a71a73503c34dc08  libxml-1.8.17-9.0.9.1.legacy.i386.rpm
4c6d4bf161a7043532c5f14937998c0b29a07776  libxml-1.8.17-9.0.9.1.legacy.src.rpm
1c2846aa583bfd690b785bc7b95bc28849e6010f 
libxml-debuginfo-1.8.17-9.0.9.1.legacy.i386.rpm
61e98749455abcb07e609588dc0c86f365e4430a 
libxml-devel-1.8.17-9.0.9.1.legacy.i386.rpm
 
fc1:
3c438b2d4f8f5cb9b886c30f3217beab35ead66a  libxml-1.8.17-9.1.legacy.i386.rpm
022e31ed5c4a9d244d98930d033542fc5ff0888d  libxml-1.8.17-9.1.legacy.src.rpm
86b3a589c708ef07cbd225623457f53ebc1a56a4 
libxml-debuginfo-1.8.17-9.1.legacy.i386.rpm
50126785351c93b593482a851b287cd187015d80  libxml-devel-1.8.17-9.1.legacy.i386.rpm
  
files:
 
rh73:
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml-1.8.17-9.0.7.3.1.legacy.src.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml-1.8.17-9.0.7.3.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml-devel-1.8.17-9.0.7.3.1.legacy.i386.rpm
 
rh9:
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml-1.8.17-9.0.9.1.legacy.src.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml-1.8.17-9.0.9.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml-debuginfo-1.8.17-9.0.9.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml-devel-1.8.17-9.0.9.1.legacy.i386.rpm
 
fc1:
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml-1.8.17-9.1.legacy.src.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml-1.8.17-9.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml-debuginfo-1.8.17-9.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/libxml-devel-1.8.17-9.1.legacy.i386.rpm
 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
 
iD8DBQFBpMd0tU2XAt1OWnsRAtghAJ9PTMPCI1rZ14AOZ6Ykkyv+jcgzQQCgiGf/
y3zwiIW69D4feRa+twWGWIg=
=jJK1
-----END PGP SIGNATURE-----




------- Additional Comments From fedora-legacy-bugzilla-2004 2004-12-06 21:41:52 ----

It seems that the files "nanoftp.o" and "nanohttp.o" have not been included in
all of RH7.3, RH9 and FC1 libxml / libxml2 RPMs.
Do these vulnerabilities affect?



------- Additional Comments From michal 2004-12-07 05:11:51 ----

> It seems that the files "nanoftp.o" and "nanohttp.o" have not been included ...
You mean in originals or in test packages?  If you mean originals then these
object files were used in putting together libraries.  At least in RH7.3 case
and I did not check others but most likely this true there as well.  Look for
symbols provided by these objects.

A random check shows that these object files are parts of libraries from
new test packages as well (although they will not show on their own).



------- Additional Comments From fedora-legacy-bugzilla-2004 2004-12-09 03:13:19 ----

>Look for symbols provided by these objects.

OK. I understood. Thanks.

Then I compiled the exploit on 
http://www.securityfocus.com/archive/1/379383/2004-10-24/2004-10-30/0 .
And test it on RH9 and FC1.
In RH9 that uses fixed or non-fixed libxml2 packages happened nothing.

In FC1 that uses non-fixed package, a segmentation error has occurred.
After updating libxml2 package, nothing happened.



------- Additional Comments From pekkas 2004-12-23 05:13:15 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

QA of libxml packages:
 - sources OK
 - spec file changes OK, though RHL73 has been updated significantly.
   Watch out for build problems.
 - patches are verified to be OK and similar to RHEL.

Note: only the rh9 one adds Buildrequires: libtool. Not sure if this was
intentional or not.

+PUBLISH RHL73,RHL9,FC1

1ea07f6ce79a97c09292080024e04968f324f0cf  libxml-1.8.17-9.0.7.3.1.legacy.src.rpm
4c6d4bf161a7043532c5f14937998c0b29a07776  libxml-1.8.17-9.0.9.1.legacy.src.rpm
022e31ed5c4a9d244d98930d033542fc5ff0888d  libxml-1.8.17-9.1.legacy.src.rpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFByuBqGHbTkzxSL7QRAqVJAKDBHYsVMQFaJsce0cElKheUOTQ1TgCeONGx
rLTq8SnOWtb4R2yYwl4rAKA=
=/D/h
-----END PGP SIGNATURE-----




------- Additional Comments From pekkas 2004-12-23 05:15:00 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

QA of libxml2 SRPMS w/ rpm-build-compare.sh.
 - source integrity is OK
 - spec file changes reasonable
 - patches are a bit trickier business, below:

 1) FC1 patches verified to come from FC3.
 2) RHL9 patches verified to be sufficient, and compared to RHEL3.
 3) RHL73 patches also OK.

There are some amount of differences with different patches (I looked at
CVS, Redhat, Debian, and Michal's).  Some patches print warnings, others do
not.  Red Hat's patch uses 'continue' in the getaddrinfo loop, others break
off (this doesn't matter here because we're assuming hostile input, so break
is OK too).

One notable difference is in nanoftp.c, however:

Michal:
< +    if ((unsigned int) hp->h_length >
< +     sizeof(((struct sockaddr_in *)&ctxt->ftpAddr.sin_addr))) {

RHEL3:
> +     if (hp->h_length >
> +         sizeof(((struct sockaddr_in *)&ctxt->ftpAddr)->sin_addr)) {

RHEL21:
> +     if (hp->h_length > sizeof(ctxt->ftpAddr.sin_addr))
> +         return(-1);

Debian stable:
> +        sizeof(((struct sockaddr_in *)&ctxt->ftpAddr)->sin_addr)) {

4 patches, 3 different ways to achieve the result.  Are these all really
equivalent -- and if not, which one(s) are correct?

FWIW, the CVS has this:

        if (hp->h_length >
                     sizeof(((struct sockaddr_in *)&ctxt->ftpAddr)->sin_addr)) {

So, I'd guess RHEL3/Debian at least have it OK.  What about the other two?

Otherwise I'd give a PUBLISH for all of these, but I'd like to get this
double checked.

(Btw, hacking your own patches makes it a LOT more time-consuming to QA..)

f9e482e80a0f80890dfd904e520178f72abbabb8  libxml2-2.4.19-7.legacy.src.rpm
543a79994c053a56598e7a69a8056ec527178766  libxml2-2.5.4-3.rh9.1.legacy.src.rpm
6b22a97268045b74308debac5a8e3121ccd5868f  libxml2-2.6.6-3.1.legacy.src.rpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFByuBxGHbTkzxSL7QRAtFeAJ4vkCyQXCkQhbPkVjmbnvJ/YkahVACggTR4
86swrcU58IaSGbj5uCaAAbE=
=7sB9
-----END PGP SIGNATURE-----



------- Additional Comments From michal 2004-12-23 06:38:29 ----

re question in comment #12:

Somewhat more context would be needed to answer if all patches are truly
equivalent; but the first three look like they are at least on 32-bit
processors.  Results of 'sizeof', by a definition, are unsigned.

I am the most careful in spelling out what conversions are done.  If 'h_length'
field is of unsigned type, which likely is not but I do not remember, then
the first cast is not needed.  The one from RHEL21 relies even more on that
that automatic promotion type rules will work as intended.  These rules are
not as obvious as it seems in the first place and I have seen many bugs,
especially when a code was recompiled on a 64-bit CPU, because somebody
misremembered something. gcc warnings about comparisons between signed
and unsigned are not a noise.

What a code from Debian is really doing I will not even start guessing.
Clearly substantial parts of a condition are missing not talking about the rest.

I also prefer to use somebody else patches, as a labor saving device,
provided they exist and are correct.  I do not remember details now but
what I wrote in October was, most likely, a "backport" of relevant code
fragments from libxml2-2.6.15 and other patches were not available at that
time.



------- Additional Comments From rob.myers.edu 2004-12-23 08:57:22 ----

re comment #11:
i assume you meant the libxml2-2.5.4-3.rh9.1.legacy.src.rpm one?

if so, yes libtool is required as it will not build in mach without it.

re comment #12 and comment #13:

is there some test or code we can write to prove that these are or are not
equivalent?  is there a way to prove that one patch is more correct than another?



------- Additional Comments From pekkas 2004-12-23 09:50:22 ----

re: #14, yes, but my main question was, was it intentional NOT to have libtool
as buildreq for RHL73 and FC1?

I hope there is some way.. otherwise we'd have to assume the CVS version is
correct.  My head starts spinning when I try to figure out the nuances there.. :)




------- Additional Comments From rob.myers.edu 2004-12-23 10:55:09 ----

re comment #15:

yes, rh73 and fc1 seem to build fine in mach without the libtool buildreq.  i
imagine there is a subtle difference in them, but i didn't investigate further.



------- Additional Comments From pekkas 2005-02-15 06:48:16 ----

I assume we'll need new packages, because nobody seems to have come up with a
good idea how to test the correctness otherwise?

I suggest we use the approach of RHEL3/Debian/libxml2 CVS for fixing nanoftp.c



------- Bug moved to this database by dkl 2005-03-30 18:28 -------

This bug previously known as bug 2207 at https://bugzilla.fedora.us/
https://bugzilla.fedora.us/show_bug.cgi?id=2207
Originally filed under the Fedora Legacy product and General component.

Attachments:
patch for problems in libxml2-2.4.19
https://bugzilla.fedora.us/attachment.cgi?action=view&id=903
libxml--1.8.17 security patch copied from Fedora updates
https://bugzilla.fedora.us/attachment.cgi?action=view&id=928

Unknown priority P2. Setting to default priority "normal".
Unknown platform PC. Setting to default platform "All".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.