---------------------------------------------- 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. KDE 1.0 on Macintosh PPC Linux is vulnerable to the klock/KDEDIR bug 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 is vulnerable to some race conditions. {details will be released at a later time} 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)