[4351] in bugtraq
Re: Overflow in xlock
daemon@ATHENA.MIT.EDU (David Hedley)
Sun Apr 27 13:48:04 1997
Date: Sun, 27 Apr 1997 14:27:08 +0100
Reply-To: David Hedley <hedley@CS.BRIS.AC.UK>
From: David Hedley <hedley@CS.BRIS.AC.UK>
X-To: George Staikos <staikos@0wned.org>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: Your message of Sat, 26 Apr 1997 16:16:05 -0400.
<Pine.LNX.3.91.970426160718.1940A-100000@warrior.0wned.org>
>>>>> "GS" == George Staikos <staikos@0wned.org> writes:
GS> There appears to be an exploitable buffer overflow in xlock, the
GS> X based screensaver/locker. Xlock is installed suid root on
GS> machines with shadowed passwords. I have verified this on xlock
GS> versions on AIX 4.x and Linux (exploit for Linux posted below),
GS> but I cannot determine what version I was using, as xlock does
GS> not seem to contain version information in the binary and I
GS> don't have the original source. The overflow is in the -name
GS> parameter, and it is fixed in xlockmore-4.01, available on
GS> sunsite in /pub/Linux/X11/screensavers/xlockmore-4.01.tgz .
GS> Other platforms have not been checked for this, and while this
GS> is an older version of xlock, many systems seem to come
GS> preloaded with this version. Also, xlock does not need to be
GS> suid root unless it is running on a machine with shadowed
GS> passwords, so another possible fix it chmod u-s xlock.
I mailed CERT at the beginning of this month about the problem with
xlock (VU#14948). I was going to give them a month or so to get a patch
organised before publishing my exploit (for Solaris 2.5.x). As far as I
know, all platforms shipped with xlock are vulnerable to this problem.
xlockmore-4.02 fixes all these problems, including one minor buffer
overflow present in xlockmore-4.01. It is available as
ftp.x.org:/contrib/applications/xlockmore-4.02.tar.gz
The following is taken from my posting to CERT:
[snip]
I have recently discovered a security hole in xlock which allows existing
users to become root. This hole is present on _all_ versions of xlock in
existence to the best of my knowledge. Including Solaris, Irix (5.3 &
6.2), FreeBSD and any other system which has xlock installed suid root.
The problem lies in xlock trusting various bits of the environment and
its command line arguments. Specifically:
$HOME
$XAPPLRESDIR
$XUSERFILESEARCHPATH
$XFILESEARCHPATH
the classname (specified via the -name parameter)
the mode (specified via the -mode parameter)
To see if you are vulnerable, simply do:
xlock -name xxxxxxxxxxxxxxxxxxxxxxxx <insert lots of x's here>
If xlock crashes with a segmentation fault or similar, then you are
vulnerable.
[snip]
David
--
David Hedley (hedley@cs.bris.ac.uk)
finger hedley@cs.bris.ac.uk for PGP key
Computer Graphics Group | University of Bristol | UK
