+++ This bug was initially created as a clone of Bug #166995 +++ This text was scavanged from the KDE advisory: 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. -- Additional comment from bressers on 2005-08-29 11:37 EST -- Created an attachment (id=118209) Proposed patch from upstream -- Additional comment from than on 2005-09-01 13:29 EST -- i have already committed the patch into CVS, it will be included in next kdebase update. -- Additional comment from mjc on 2005-09-06 09:12 EST -- Public via bugtraq, removing embargo -- note we don't ship anything with /var/lock world writeable. -- Additional comment from deisenst on 2006-02-05 02:24 EST -- Hi, I am working on this bug for Fedora Legacy. I note for the Fedora Core 4 version of this bug (Bug #166997) that you CLOSED NOTABUG on this same issue. Are you intending to close this also NOTABUG? Or is it remotely possible that a sysadmin may decide, for whatever reason, to make his or her /var/lock world writeable? Please let me know. Thanks. -David
Note, if this is indeed considered a security vulnerability, it would affect FC2 and FC3, but none of the other distros that Legacy works with. What do you all think??
Josh Bressers responded (in Bug #166995): "We won't be closing this as NOTABUG. The previous bug should have been closed ERRATA, I'm guessing it was a simple wrong click. We will fix this, but not until we have a different issue to fix in kdebase. This issue has an impact of 'LOW', which means we won't release an update just for this particular issue." "It's unlikely anyone would have their /var/lock world writeable, but it never hurts to err on the side of caution." Changing this to NEEDSWORK.
Re-entering this from my email cache. ------- Additional Comments From deisenst 2006-06-10 18:34 EST ------- New vulnerability: CVE-2006-2449 kdebase- KDM symlink attack vulnerability
------- Additional Comments From deisenst 2006-06-10 18:39 EST ------- More info from vendor-sec: Summary: Ludwig Nussel discovered a vulnerability within KDM. Description: KDM allows the user to select the session type for login. This setting is permanently stored in the user home directory. By using a symlink attack, KDM can be tricked into allowing the user to read file content that would otherwise be unreadable to this particular user. This vulnerability was discovered and reported by Ludwig Nussel. Affects: KDM as shipped with KDE 3.2.0 up to including 3.5.3. KDE 3.1.x and older and newer versions than KDE 3.5.3 are not affected. Doesn't affect FC1 or earlier, according to KDE security. Impact: KDM might allow a normal user to read the content of [arbitrary system] files, which allows compromising the privacy of another user or even the security of the whole system.
Red Hat today issued RHSA-2006-0548 today for CVE-2006-2449: <http://rhn.redhat.com/errata/RHSA-2006-0548.html> "Ludwig Nussel discovered a flaw in KDM. A malicious local KDM user could use a symlink attack to read an arbitrary file that they would not normally have permissions to read. (CVE-2006-2449) "Note: this issue does not affect the version of KDM as shipped with Red Hat Enterprise Linux 2.1 or 3. "All users of KDM should upgrade to these updated packages which contain a backported patch to correct this issue." This CVE-2006-2449 issue does not RHL 7.3, RHL 9, nor FC1. It only affects FC2 and FC3. Lifting embargo.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've created updated packages for FC2 and FC3. Please take a look at them - it's been a while since I've done this :) FC2 Package: http://www.cs.ucsb.edu/~jeff/legacy/kdebase/kdebase-3.2.2-8.FC2.1.legacy.src.rpm 5864ce63c1a1a9ccb2754015feddc746b6dc126e kdebase-3.2.2-8.FC2.1.legacy.src.rpm FC3 Package: http://www.cs.ucsb.edu/~jeff/legacy/kdebase/kdebase-3.4.2-0.fc3.3.1.legacy.src.rpm 2bf134f0f92c7141728937b665c3bb87dcdaf339 kdebase-3.4.2-0.fc3.3.1.legacy.src.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFEmxVAKe7MLJjUbNMRAiDSAKCqveZT0stfPmKsIgfu9SDhYIVZkgCfcOaC /SlX+TbnfsREoMds29K6nwE= =y09i -----END PGP SIGNATURE-----
Thanks Jeff! I'll try & have a look at it in the next few days, Jeff. Both you and Marc do great work, so I do not doubt things'll be ship-shape! :) By the same token, you are welcome to QA at the sources in the sendmail bug if you wish. :) -David
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 PUBLISH QA for kdebase FC2, FC3: 5864ce63c1a1a9ccb2754015feddc746b6dc126e__kdebase-3.2.2-8.FC2.1.legacy.src.rpm 2bf134f0f92c7141728937b665c3bb87dcdaf339__kdebase-3.4.2-0.fc3.3.1.legacy.src.rpm * sha1sums are good; * FC2 kdebase-3.2.2-kcheckpass_escalation.patch matches upstream's post-3.4.2-kdebase-kcheckpass.diff for CVE-2005-2494 vulnerabilty; * FC2 kdebase-3.2.2-kdebase-kdm.patch matches upstream's post-3.2.0-kdebase-kdm.diff patch for CVE-2006-2449 vulnerability; * Changes in FC2 .spec file look minimal and good. * FC3 kdebase-3.2.2-kcheckpass_escalation.patch matches upstream's post-3.4.2-kdebase-kcheckpass.diff for CVE-2005-2494 vulnerabilty; * FC3 kdebase-3.4.2-kdebase-kdm.patch matches upstream's post-3.5.0-kdebase-kdm.diff, except that this patch adds an extra blank line to the resulting source file. (Or, conversely, the up- stream's patch file deletes an additional blank line.) * FC3 .spec file changes minimal and good. PUBLISH++ FC2, FC3 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFEnOVSxou1V/j9XZwRAi9eAJ9yMUAAmFikhRNZycm2ouAXQFJwugCfRn/4 bcfj6Z3svpkC9sBpXq8Sodo= =FcPC -----END PGP SIGNATURE----- Oh, these are building right now on turbosphere...
Cool, thanks for the QA. Actually, I had already built those packages on turbosphere, but that's OK, now we have extras :)
(In reply to comment #9) > Cool, thanks for the QA. Actually, I had already built those packages on > turbosphere, but that's OK, now we have extras :) Oooops! :) These will need pushing to updates-testing then.
2 months later, beard has a few more grey hairs ... So I can't remember. Did these build okay on turbosphere? If so, can't these be pushed to updates-testing? I don't have the privileges to do it, but I believe at least Jesse Keating and Marc Deslauriers has the privileges to move these to updates-testing. Anyone else?
Hi David, yes, we both built them on turbosphere. Mine were: http://turbosphere.fedoralegacy.org/build/job.psp?uid=150 and http://turbosphere.fedoralegacy.org/build/job.psp?uid=151 yours were: http://turbosphere.fedoralegacy.org/build/job.psp?uid=152 and http://turbosphere.fedoralegacy.org/build/job.psp?uid=153 As far as I know, Marc and Jesse are the only ones with the special power to get these signed and into updates-testing.
Fedora Core 3 is now completely unmaintained. These bugs can't be fixed in that version. If the issue still persists in current Fedora Core, please reopen. Thank you, and sorry about this.