[8593] in bugtraq

home help back first fref pref prev next nref lref last post

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

home help back first fref pref prev next nref lref last post