Bug 472109 - (CVE-2008-5138) CVE-2008-5138 pam_mount temporary file symlink attack
CVE-2008-5138 pam_mount temporary file symlink attack
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 472110 472111 472112
  Show dependency treegraph
Reported: 2008-11-18 15:07 EST by Josh Bressers
Modified: 2015-08-22 11:46 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-08-22 11:46:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Josh Bressers 2008-11-18 15:07:15 EST
passwdehd in libpam-mount 0.43 allows local users to overwrite
arbitrary files via a symlink attack on a /tmp/passwdehd.#####
temporary file.

Comment 1 Josh Bressers 2008-11-18 15:07:47 EST
Created pam_mount tracking bugs for this issue

CVE-2008-5138 Affects: F8 [bug #472110]
CVE-2008-5138 Affects: F9 [bug #472111]
CVE-2008-5138 Affects: Fdevel [bug #472112]
Comment 2 Till Maas 2008-11-18 17:12:30 EST
I need some guidance here. In the pam_mount version in F8 & F9 stable and devel, the script will not work, because the config file of pam_mount changed and the script was not ported to the new format. Also in newer upstream releases, the script is not shipped anymore. The only action the script would take on an up2date Fedora system would be to write, that the config file cannot be found. The question is now, how to proceed. The initial release of F8 (maybe F9, too) included an rpm where the script still worked somehow, but there was already another security update that included the config file change. The question is now, whether I should create a new update that does not include the affected script to make everyone aware that this vulnerability existed via the repository metadata and package update mailinglist, so that the administrators can decide, whether or not they want to upgrade.

Fedora devel is imho not really affected, therefore I guess the bug can be closed.
Comment 3 Till Maas 2008-11-18 17:33:06 EST
The config file was renamed from /etc/security/pam_mount.conf to /etc/security/pam_mount.conf.xml with pam_mount 0.19, maybe you can forward this information to the debian people.
Comment 4 Tomas Hoger 2008-11-23 15:38:44 EST
Till, is that likely that admins have some left-over pam_mount.conf file besides pam_mount.conf.xml?  Even users that installed version that still used pam_mount.conf should have that file either removed during upgrade (if it was unchanged), or renamed to .rpmsave.

Btw, why should Rawhide be less affected than F8/F9?  All versions use 0.49, so all should be affected in pretty much the same way.

As for updating now vs. later, given that this has quite low impact, further lowered by the fact that the problematic part of the script is unlikely to be reached on users' systems, it should be fine to postpone fixing this until there's another reason to do new spin of pam_mount packages (either bug or update to newer upstream version).
Comment 5 Till Maas 2008-11-23 17:41:05 EST
It is very unlikely that a pam_mount.conf file still exists on systems that have updated to pam_mount 0.49. But maybe some admins did not yet update their pam_mount package, because of the change to the XML file format or for some other reasons.

Imho F10/devel is less affected, because there it is made sure that everyone is having pam_mount 0.49 and therefore there will be no pam_mount.conf file.

Note You need to log in before you can comment on or make changes to this bug.