Systems running KDE 1.0


    HD Moore  found following.   The SUID  program klock  shipped with
    KDE 1.0 attempts to  execute kblankscrn.kss in the  same directory
    as it.  If kblankscrn.kss cannot be executed (missing or mode  -x)
    then klock will search the current user's $PATH for any executable
    with the same name  and execute it as  ROOT.  If no  executable is
    found in the current path it gives this message:

        >Could not invoke kblankscrn.kss in $PATH or /opt/kde/bin

    Default modes for klock and kblankscrn.kss are:

        -rwsr-xr-x   1 root     root         8760 Mar 12  1998 /opt/kde/bin/klock
        -rwsr-xr-x   1 root     root        43600 Mar 12  1998 /opt/kde/bin/kblankscrn.kss

    This is only exploitable if any of the following occurs:

        1) klock is moved to another directory
        2) kblankscrn.kss is moved to another directory
        3) kblankscrn.kss is not executable

    To see if you are vulnerable...

        1) as root, chmod 600 /opt/kde/bin/kblankscrn.kss
        2) login as a normal user
        3) create a shell script thats looks like:

           echo Running script as `whoami`!

        4) name  this script  to kblankscrn.kss  and mv  to your  home
        5) execute /opt/kde/bin/klock, you should see:

           user@hostname:/home/user> /opt/kde/bin/klock
           user@hostname:/home/user> Running script as root!

        6) as root, chmod 755 /opt/kde/bin/kblankscrn.kss

    Further  examination  reveals  more,  and  more  serious  security
    vulnerabilities in both klock,  and kppp (by David.  G. Andersen).
    The general problem is  that KDE trusts user  supplied environment
    variables too much.  This trust leads to several problems:

    Trust of "" file contents
    Arbitrary processes may be killed by klock, because KDE trusts the
    content of the "" 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

        setenv HOME "/tmp"
        echo thepid > /tmp/

    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 );

    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

    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);


    chmod 700 /opt/kde/bin/klock  or wait until  KDE is updated.   The
    KDE team has now  published  a fix  for the KDE1.0 branch  and the
    current branch.  With this change, screensavers and klock are  not
    running SUID anymore.   This will solve  every potential  exploit,
    like misuse of buffer overruns to gain root rights or executing  a
    wrong  executable  under  SUID  rights.   The  patches are already
    integrated in  the KDE1.0  and the  KDE1.1 branches.   You can use
    cvs/cvsup to get current sources.  You can also get the patch from
    KDE's ftp Server

   Also, don't forget chmod a-s klock kppp