Date: Wed, 18 Nov 1998 11:15:02 -0700 From: "David G. Andersen" <danderse@CS.UTAH.EDU> Subject: Multiple KDE security vulnerabilities (root compromise) 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