[KLUG Members] Re: New on BSware this week - a LOT!
Jamie McCarthy
members@kalamazoolinux.org
Tue, 26 Jun 2001 12:16:30 -0400
bruce@armintl.com (Bruce Smith) writes:
> 14674278 XFree86-3DLabs-3.3.6-38.i386.rpm
> 12733008 XFree86-8514-3.3.6-38.i386.rpm
> 13539848 XFree86-AGX-3.3.6-38.i386.rpm
> 13837028 XFree86-FBDev-3.3.6-38.i386.rpm
> 13394858 XFree86-Mach32-3.3.6-38.i386.rpm
> 13931508 XFree86-Mach64-3.3.6-38.i386.rpm
> 12772658 XFree86-Mach8-3.3.6-38.i386.rpm
> 13444308 XFree86-Mono-3.3.6-38.i386.rpm
> 13623918 XFree86-P9000-3.3.6-38.i386.rpm
> 15649938 XFree86-S3-3.3.6-38.i386.rpm
> 14523918 XFree86-S3V-3.3.6-38.i386.rpm
> 19342978 XFree86-SVGA-3.3.6-38.i386.rpm
> 13533898 XFree86-VGA16-3.3.6-38.i386.rpm
> 12918348 XFree86-W32-3.3.6-38.i386.rpm
Do upgrade, too, because among the XFRee86 bugfixes are quite a few
issues that sound pretty serious to me:
> 1629. [SECURITY] Check for negative reply length/overflow in _XAsyncReply
> (Xlib) (#4601, Mike Harris).
> 1624. [SECURITY] fix possible buffer overflow (NOT on stack) in xdm
> xdmcp code (patch69 from Red Hat SRPMS).
> 1623. [SECURITY] Pull fixed from 4.0.2 for following problems:
> - XlibInt buffer overflow
> - libICE denial of service
> - XOpenDisplay buffer overflow (#4450, Branden Robinson)
> 1621. [SECURITY]: Fix temp file problem in Imake.rules,
> InstallManPageAliases (Matthieu Herrb)
> 1620. [SECURITY]: Pull fixes from the main branch:
> - XCSECURITY DoS (Paulo Caesar Pereira de Andrade and Keith Packard),
> - _XAsyncReply() Xlib stack corruption,
> - Xaw temp file handling (Branden Robinson).
> 1619. [SECURITY] Safe tempfile handline for imake's probing of glibc
> version (based on #4257, Colin Phipps).
> 1616. [SECURITY] Fix a 1-byte overflow in Xtrans.c (#4182, Aaron Campbell).
> 1615. [SECURITY] Back port fix for
> http://www.securityfocus.com/archive/1/139436 from 4.0
> (#4181, Matthieu Herrb).
> 1611. [SECURITY] Fix tmp file problem with makedepend scripts (based on
> report from Alan Cox).
> 1605. [SECURITY] Fix a buffer overflow with the -xkbmap X server flag
> (#A.91, Trevor Johnson).
> 1590. [SECURITY] Fix possible races in xauth and libXau (#3690, 3694,
> Colin Phipps).
I found this interesting thread about Red Hat on bugtraq, in my pile
of accumulated mail...
====== Forwarded Message ======
Date: 6/19/01 4:40 PM
Received: 6/19/01 8:14 PM
From: bugzilla@redhat.com
To: redhat-watch-list@redhat.com
---------------------------------------------------------------------
Red Hat, Inc. Red Hat Security Advisory
Synopsis: Format string bug fixed
Advisory ID: RHSA-2001:078-05
Issue date: 2001-06-11
Updated on: 2001-06-19
Product: Red Hat Powertools
Keywords: format string local
Cross references:
Obsoletes:
---------------------------------------------------------------------
1. Topic:
A locally exploitable format string bug has been fixed in the code that
handles batch SMTP.
2. Relevant releases/architectures:
Red Hat Powertools 6.2 - alpha, i386, sparc
Red Hat Powertools 7.0 - alpha, i386
Red Hat Powertools 7.1 - i386
[...]
====== End Forwarded Message ======
====== Forwarded Message ======
Date: 6/20/01 2:14 PM
Received: 6/20/01 11:13 AM
From: p.mayers@ic.ac.uk (Mayers, Philip J)
To: bugzilla@redhat.com ('bugzilla@redhat.com')
That's great - but did you even *bother* to check if the update works on
RedHat 7.0?
[root@unix-software i386]# cat /etc/redhat-release
Red Hat Linux release 7.0 (Guinness)
[root@unix-software i386]# rpm -qp --requires exim-3.22-13.i386.rpm
<snip>
libcrypto.so.1
<snip>
libssl.so.1
<snip>
[root@unix-software i386]# rpm -qa --provides | egrep 'libssl|libcrypto'
libcrypto.so.0
libssl.so.0
libssl.so
[root@unix-software i386]# rpm -q openssl --provides
libcrypto.so.0
libssl.so.0
openssl = 0.9.5a-14
[root@unix-software i386]# rpm -Uvh exim-3.22-13.i386.rpm
error: failed dependencies:
libcrypto.so.1 is needed by exim-3.22-13
libssl.so.1 is needed by exim-3.22-13
*Wonderful* - you've shipped an update that no-one can apply, unless they
update their OpenSSL package (an update you don't provide). Doubtless you
built the RPM on RedHat 7.1, which has OpenSSL 0.9.6 and libcrypto.so.1
I like RedHat, but this is the third time you've done something like this in
recent months:
1) Splitting glibc into glibc-common and glibc, which meant that the glibc
update could not automatically be applied
2) Breaking the init script for the OpenSSH 2.5.2 release, which meant that
if anyone applied the update whilst logged in over SSH, the SSH daemon
restarted - this was because you switched to using the newer initscripts,
which had a function in them that the older ones didn't.
3) Now this, an (old, not even version 3.30) Exim update that won't apply!
Don't even get me started on the RPM4 update to 6.2, or the LDAP and crypto
libraries (which weren't a core part of the system when you shipped it, but
you made essential later on) - annoyingly enough, after making such sweeping
changes you didn't ship OpenSSH (although you already had OpenSSL) for 6.2.
You might take a lead from Debian's book, and exercise a little bit of
discipline when making your packages, rather than letting a random intern
ship updates to systems that people are using *in production*. Can I make a
suggestion - when developing patches for an operating system, try doing it
on the right version of the damn OS, rather than against RawHide, or
whatever it is you do...
Could you please re-issue this update, compiled on the right system this
time?
Regards,
Phil
+----------------------------------+
| Phil Mayers, Network Support |
| Centre for Computing Services |
| Imperial College |
+----------------------------------+
-----Original Message-----
From: bugzilla@redhat.com [mailto:bugzilla@redhat.com]
Sent: 19 June 2001 21:40
To: redhat-watch-list@redhat.com
Cc: bugtraq@securityfocus.com; linux-security@redhat.com;
security@redhat.com
Subject: [RHSA-2001:078-05] Format string bug fixed
<snip broken update report>
====== End Forwarded Message ======
====== Forwarded Message ======
Date: 6/22/01 2:02 PM
Received: 6/25/01 1:29 PM
From: dummkopf@physics.ucsc.edu (helmut g. katzgraber)
To: storage@iewebs.com
note also the following which is a total confusion: redhat
packages LPRng on their own with the latest release being
LPRng-3.7.4-23 .
while binaries compiled for 7.x exists, the sources cannot
be downloaded from their servers, at least till yesterday.
if you now go to patrick powells site (developer of LPRng)
located at http://www.astart.com/LPRng/LPRng.html you will
find that the latest release of LPRng he offers there is
LPRng-3.7.4-1 (in rpm format)
and
LPRng-3.7.4.tgz (src)
the questions are: what are the differences between the
version offered by redhat and the version offered by patrick
powell? has the rpm offered on the lprng site also
the same problems as the redhat one (advisory
RHSA-2001:077-05)?
if you are using redhat 6.x and use LPRng you cannot use the
rpms provided by redhat since they are for rh 7.x. you will
run into incompatibilities. will then upgrading to version
LPRng-3.7.4-1 from the lprng site solve the problems? little
detail is that the rpms provided on the lprng site wont work
because of dependencies. you will have to get the src rpm
and rebuild it. then they will install.
cheers, h.
ps: note also that if you grab the src rpm from the lprng
site and try to rebuild the rpm for alpha arch it will
bomb and not compile, i.e if you have an alpha with rh 6.x
and need LPRng you are stuck with a 3.6.x version...
_________________________________________________________
Helmut G. Katzgraber
Physics Department, Kerr Hall
University of California Phone: (+1) 831-459-4762
Santa Cruz, CA 95064, USA Fax: (+1) 831-459-3043
====== End Forwarded Message ======
--
Jamie McCarthy
jamie@mccarthy.vg