5161698 2000-06-05 04:13 /67 rader/ Postmaster
Mottagare: Bugtraq (import) <11153>
Ärende: Linux-Mandrake Xlockmore security update
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.6
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID: <m2hfb96xke.fsf@vador.mandrakesoft.com>
Date: Sun, 4 Jun 2000 21:44:17 +0200
Reply-To: Chmouel Boudjnah <chmouel@MANDRAKESOFT.COM>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Chmouel Boudjnah <chmouel@MANDRAKESOFT.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
-------------------------------------
Linux-Mandrake Security Update
-------------------------------------
Package: xlockmore
Affected versions: 6.1, 7.0
Problem: Xlock is an X11 utility used to lock X-Window displays until
the password of the user running X is entered correctly. Of course, in
order to perform the password-check xlock must be setuid root and have
access to the shadowed passwd file. In the xlockmore distributions
versions prior to 4.16.1, a buffer overflow vulnerability was present
in xlock that permitted a user to view parts of the shadowed passwd
file. This is achieved by overwriting (with an oversized -mode
argument) a global variable storing a pointer to a string printed in
the "usage" output. The pointer would be overwritten with an address
pointing to the shadowed passwd data. With the long argument, xlock
would find and an error in the command syntax and exit, printing the
usage information (along with the shadowed passwd text).
Please upgrade to:
md5sum: 614600a41689677da12287b950c2708a
package: 6.1/RPMS/xlockmore-4.16.1-1mdk.i586.rpm
md5sum: d0a6a3bf840b4d3ea347892f8df1896e
source: 6.1/SRPMS/xlockmore-4.16.1-1mdk.src.rpm
md5sum: 82ea685b6c467a55fce37490286763ae
package: 7.0/RPMS/xlockmore-4.16.1-1mdk.i586.rpm
md5sum: d0a6a3bf840b4d3ea347892f8df1896e
source: 7.0/SRPMS/xlockmore-4.16.1-1mdk.src.rpm
To upgrade automatically, use « MandrakeUpdate ». If you want to
upgrade manually, download the updated package from one of our FTP
server mirrors and uprade with "rpm -Uvh package_name". All mirrors
are listed on http://www.mandrake.com/en/ftp.php3 Updated packages are
available in the "updates/" directory.
For example, if you are looking for an updated RPM package for
Mandrake 7.0, look for it in: updates/7.0/RPMS/
Note: we give the md5 sum for each package. It lets you check the
integrity of the downloaded package by running the md5sum command on
the package ("md5sum package.rpm").
--
MandrakeSoft Inc http://www.mandrakesoft.com
--Chmouel
(5161698) ------------------------------------------
5166668 2000-06-06 09:37 /37 rader/ Postmaster
Mottagare: Bugtraq (import) <11163>
Ärende: Re: Linux-Mandrake Xlockmore security update
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20000605143914.DA698186AC@atlas.dgp.toronto.edu>
Date: Mon, 5 Jun 2000 10:39:14 -0400
Reply-To: Alan J Rosenthal <flaps@DGP.TORONTO.EDU>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Alan J Rosenthal <flaps@DGP.TORONTO.EDU>
To: BUGTRAQ@SECURITYFOCUS.COM
>Of course, in order to perform the password-check xlock must be setuid root
>and have access to the shadowed passwd file.
Well, no. It needs read access to the shadow password file, and
that's it, and it doesn't need to be setuid root.
If you create a special "shadow gid" for use only by programs which
need only read access to /etc/shadow, and put /etc/shadow in group
shadow (still owned by root) and make it mode 640, then you can make
programs such as xlock(more) setgid shadow and thus give them no
other additional ability than to read /etc/shadow.
We might not want to get into hundreds of specialized groups for
special abilities to be granted to individual programs (although some
would surely argue that we should), but I think that anything big,
which includes anything which is an X client because the X libraries
are big, should not be setuid root if at all possible.
Some capabilities are equivalent to root. "passwd" only needs to be
able to read *and*write* /etc/shadow, but there's no sense in using a
special group for this because the ability to write to /etc/shadow is
equivalent to root.
But the ability to *read* /etc/shadow is far short of compromising
root (it's simply the situation everyone was in before shadowed
passwords came about), and worth distinguishing from setuid root,
especially for X clients.
ajr
(5166668) ------------------------------------------(Ombruten)