Bug 104099 – kde-base/kdebase kcheckpass local root vulnerability

• Status: RESOLVED WORKSFORME
• Product: Gentoo Security

[Description Sune Kloppenborg Jeppesen (RETIRED) 2005-08-28 22:32:22 UTC]

KDE Security Advisory: kcheckpass local root vulnerability 
Original Release Date: 2008-09-05 
URL: http://www.kde.org/info/security/advisory-20050905-1.txt 
 
0. References 
 
        CAN-2005-FIXME 
 
1. Systems affected: 
 
        All KDE releases starting from KDE 3.2.0 up to including 
        KDE 3.4.2. 
 
 
2. Overview: 
 
        Ilja van Sprundel from suresec.org notified the KDE 
        security team about a serious lock file handling error 
        in kcheckpass that can, in some configurations, be used 
        to gain root access. 
 
        In order for an exploit to succeed, the directory /var/lock 
        has to be writeable for a user that is allowed to invoke 
        kcheckpass. 
 
 
3. Impact: 
 
        A local user can escalate its privileges to the root user. 
 
 
4. Solution: 
 
        Source code patches have been made available which fix these 
        vulnerabilities. Contact your OS vendor / binary package provider 
        for information about how to obtain updated binary packages. 
 
 
5. Patch: 
 
        Patch for KDE 3.4.2 is available from  
        ftp://ftp.kde.org/pub/kde/security_patches : 
 
        86f7d6fd68568dfd1edcae453958ba31  post-3.4.2-kdebase-kcheckpass.diff

[Comment 1 Sune Kloppenborg Jeppesen (RETIRED) 2005-08-28 22:33:12 UTC]

Created attachment 67134 [details, diff]
post-3.4.2-kdebase-kcheckpass.diff

[Comment 2 Sune Kloppenborg Jeppesen (RETIRED) 2005-08-28 22:34:53 UTC]

KDE please attach updated ebuilds. Do NOT commit to Portage. 

[Comment 3 Thierry Carrez (RETIRED) 2005-08-29 00:36:37 UTC]

"In order for an exploit to succeed, the directory /var/lock has to be writeable
for a user that is allowed to invoke kcheckpass."

$ ls -ld /var/lock
drwxrwxr-x  3 root uucp 4096 ao

[Comment 4 Thierry Carrez (RETIRED) 2005-08-29 00:36:37 UTC]

"In order for an exploit to succeed, the directory /var/lock has to be writeable
for a user that is allowed to invoke kcheckpass."

$ ls -ld /var/lock
drwxrwxr-x  3 root uucp 4096 aoû 29 09:18 /var/lock

Not sure we are affected...

[Comment 5 Sune Kloppenborg Jeppesen (RETIRED) 2005-08-29 01:01:28 UTC]

Perhaps not in standard configuration, that was why I rated it B1? 

[Comment 6 Thierry Carrez (RETIRED) 2005-08-29 07:55:45 UTC]

Hm. Changing /var/lock ownership is not a "configuration" option for kcheckpass,
it's a serious change. I would say Gentoo is not affected by this vulnerability
as it ships /var/lock with the correct permissions...

Otherwise all packages using tmpfiles would be "vulnerable to symlink attacks"
in case someone plays with /tmp permissions...

I would close this one as WORKSFORME.

[Comment 7 Sune Kloppenborg Jeppesen (RETIRED) 2005-08-29 08:49:12 UTC]

KDE if you agree we'll close this one. 

[Comment 8 Carsten Lohrke (RETIRED) 2005-08-29 09:46:39 UTC]

fyi: My Gentoo box is (sort of) dead atm., so I can't build/test anything unless
I have replaced it, but I think this is a non-issue, too.

[Comment 9 Sune Kloppenborg Jeppesen (RETIRED) 2005-08-29 09:49:17 UTC]

Thx Carlo -> Closing. 

[Comment 10 Tavis Ormandy (RETIRED) 2005-09-14 12:52:06 UTC]

opening

[Comment 11 Stefan Cornelius (RETIRED) 2005-09-14 12:52:13 UTC]

*** Bug 105997 has been marked as a duplicate of this bug. ***