[8593] in bugtraq
Multiple KDE security vulnerabilities (root compromise)
daemon@ATHENA.MIT.EDU (David G. Andersen)
Wed Nov 18 13:51:48 1998
Date: Wed, 18 Nov 1998 11:15:02 -0700
Reply-To: "David G. Andersen" <danderse@CS.UTAH.EDU>
From: "David G. Andersen" <danderse@CS.UTAH.EDU>
To: BUGTRAQ@NETSPACE.ORG
With many apologies to the KDE people and affected vendors - an early
morning brain freeze and I interacted to release this advisory to the
wrong mailing list this morning, instead of giving the vendor some
time to react. Fortunately, HD Moore had previously notified KDE
of a related vulnerability, and perhaps one root hole begets
another. :)
-Dave
----------------------------------------------
Security Bulletin
November 18, 1998
Numerous Vulnerabilities in KDE 1.0
----------------------------------------------
DESCRIPTION
The K Desktop Environment (KDE) provides an integrated graphical
desktop environment for UNIX workstations. As a part of this
environment, it supplies its own PPP implementation (kppp) and its own
screen locking environment (klock), both of which are installed setuid
root. Both of these programs have numerous security vulnerabilities
which can expose the computer to a root compromise by a local user.
IMPACT
Local users may obtain root priviledges, kill local processes,
or create hidden directories on any local filesystem.
AFFECTED PLATFORMS
KDE 1.0 on FreeBSD (x86) and Linux (x86) appear vulnerable.
Other platforms have not been tested and should be
presumed vulnerable.
DETAILS
On November 16, 1998, HD Moore posted an advisory about flaws
in KDE's klock program in which it was noted that the program
will exec "blankscrn.kss" in the user's path if the ordinary .kss file
could not be located. Further examination reveals more, and more
serious security vulnerabilities in both klock, and kppp.
The general problem is that KDE trusts user supplied environment
variables too much. This trust leads to several problems:
Trust of ".kss.pid" file contents:
Arbitrary processes may be killed by klock, because KDE trusts the
content of the ".kss.pid" file, containing the process ID of other
running klock processes. If it finds them, it kills them. A
user can place an arbitrary PID in this file, which klock will
kill, as root.
setenv HOME "/tmp"
echo thepid > /tmp/.kss.pid
klock
A race condition (TTCTTOU flaw) in locating kblankscrn.kss:
Obviously, the problem found by HD Moore can take advantage of the
race condition between the two execlp's that klock calls. From
the KDE code:
execlp( buffer, buffer, "-test", "-lock", 0 );
execlp("kblankscrn.kss","kblankscrn.kss","-test","-lock",0);
This is less trivially exploitable, but is still serious, and
can lead to root compromise.
KDE trusts the value of the KDEDIR environment variable.
In numerous locations, KDE uses the value returned by kde_bindir
to locate its executables. The value of this is determined by
the KDEDIR environment variable. In the klock case, KDE uses
this directory as the initial search path for locating the
screensaver to be executed, which it does as root:
setenv KDEDIR /tmp
echo "#!/bin/sh" > /tmp/kblankscrn.kss
echo "id" >> /tmp/blankscrn.kss
chmod +x /tmp/blankscrn.kss
klock
This flaw has similar ramifications in kppp.
kppp trusts the value of the HOME environment variable:
When kppp starts up, it attempts to create a set of nested
directories to contain logfiles and configuration files.
To locate these files, it uses the value of the HOME
environment variable, and the make_directories function
uses this to create a ".kde" directory as root. Within
this directory, it creates several subdirectories which
are owned by the user. The result is that a user can create
a ".kde" directory in an arbitrary location (potentially
overwriting another user's .kde directory), with writable
scratch space contained within.
kppp fails to check the length of the PATH environment variable
when copying its contents into a static buffer:
if(getenv("PATH") != NULL)
strncat(path, getenv("PATH"), sizeof(path)-512);
REMEDY
chmod a-s klock kppp
VENDOR CONTACTS
FreeBSD:
http://www.freeBSD.org/
FreeBSD makes KDE available as a port; it is not installed
by default.
Caldera:
http://www.caldera.com/
Caldera's website indicates that they ship KDE as a standard
component, but I haven't tested a Caldera system to see
if it is vulnerable.
KDE:
http://www.kde.org/
SEE ALSO
http://www.geek-girl.com/bugtraq/1998_4/0478.html
(original posting by HD Moore)
--
work: danderse@cs.utah.edu me: angio@pobox.com
University of Utah http://www.angio.net/
Department of Computer Science