Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Nov 1998 10:45:25 -0700 (MST)
From:      "David G. Andersen" <danderse@cs.utah.edu>
To:        lnielson@hottub.caldera.com
Cc:        cert@cert.org, security@FreeBSD.ORG, wuebben@kde.org
Subject:   KDE vulnerability
Message-ID:  <13907.1747.809056.393231@torrey.cs.utah.edu>

next in thread | raw e-mail | index | archive | help

Just a note.  I haven't released this yet, though I've sent
a copy to CERT and a few other interested parties.  I received word
from Aleph1 (@bugtraq) that he approved a posting earlier today which
hints at the problems this advisory addresses.  Even a not-too-clueful 
hacker will likely be able to figure it out.

(cert, kde, freebsd, etc., here's the more updated advisory)

   -Dave

-- 
work: danderse@cs.utah.edu                     me:  angio@pobox.com
      University of Utah                            http://www.angio.net/
      Department of Computer Science


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


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13907.1747.809056.393231>