Bugzilla – Bug 870433
VUL-0: CVE-2014-2583: pam: pam_timestamp path injection
Last modified: 2016-02-05 03:43:35 UTC
via Sebastian and oss-sec: Hi When playing with some PAM modules for my own projects, I came across some implications of pam_timestamp (which is part of upstream linux-pam) that should probably be addressed. Most importantly, there seems to be a path traversal issue: static int format_timestamp_name(char *path, size_t len, const char *timestamp_dir, const char *tty, const char *ruser, const char *user) { if (strcmp(ruser, user) == 0) { return snprintf(path, len, "%s/%s/%s", timestamp_dir, ruser, tty); } else { return snprintf(path, len, "%s/%s/%s:%s", timestamp_dir, ruser, tty, user); } } If attacker can control PAM_RUSER or PAM_TTY item and pam_timestamp is "sufficient", (it makes sense to have it sufficient, as it aims to mimic sudo timestamp tickets and is suggested so in the man page) they can bypass authentication. PAM_RUSER is set in vsftpd or sssd for example. PAM_TTY can be set via dbus in gdm's x11-display variable. That has the following impact: 1. For authentication, this can allow to bypass the auth process, depending on interal app logic and the existance of certain root owned files (the file size is checked to match certain value, but chances are that such files exist somewhere under /). For openssh, if accidently included via auth-common, this can be dangerous, as the PAM_TTY is always set to "ssh". However due to PAM_TTY_KLUDGE #ifdef and internal sshd logic this probably is no issue as of today. 2. When a vector is also handling pam sessions (sssd), this bug also allows to create arbitrary files when the timestamp file is created and I guess content can be crafted with so much love to create fake shadow-file entries is possible. One should probably take care to not accidently include pam_timestamp in a config file for a remote service, as chance is high that the RUSER/TTY is used incorrectly, even when the user string is checked via getpwnam(). It should probably be documented in pam_timestamp's manpage. We are not using pam_timestamp in any of our configs, but might be that someone else is. Even if not, I think a lot of admins do. regards, Sebastian References: http://comments.gmane.org/gmane.comp.security.oss.general/12430
bugbot adjusting priority
From: cve-assign@mitre.org Subject: [oss-security] Re: pam_timestamp internals Date: Wed, 26 Mar 2014 16:05:50 -0400 (EDT) > I came across some implications of pam_timestamp ... it aims to mimic > sudo timestamp tickets > there seems to be a path traversal issue Use CVE-2014-2583. As usual, there are not separate CVE IDs for the different impacts. > One should probably take care to not accidently include pam_timestamp in a config file > for a remote service, as chance is high that the RUSER/TTY is used incorrectly, even > when the user string is checked via getpwnam(). It should probably be documented in > pam_timestamp's manpage. There is no CVE ID for the issue in which the documentation might not be sufficient to prevent all problematic uses of pam_timestamp in conjunction with remote services. The documentation at http://www.linux-pam.org/Linux-PAM-html/sag-pam_timestamp.html and elsewhere specifically mentions "This is similar mechanism which is used in sudo" and "FILES /var/run/sudo/..." in fairly prominent ways. The documentation is not directly misleading, i.e., there doesn't seem to be any implication that a remote service is a recommended use case. - -- CVE assignment team, MITRE CVE Numbering Authority
Affected packages: SLE-11-SP3: pam SLE-10-SP3-TERADATA: pam
From: "Dmitry V. Levin" <ldv@altlinux.org> Date: Mon, 31 Mar 2014 14:32:09 +0400 Subject: Re: [oss-security] pam_timestamp internals Thanks, Sebastian! The issue has been fixed in upstream linux-pam by commit https://git.fedorahosted.org/cgit/linux-pam.git/commit/?id=Linux-PAM-1_1_8-32-g9dcead8
from sebastian: Thanks for taking care. I was about to write a patch on my own, but seems not necessary anymore. However, I think that + if (!strlen(tty) || !strcmp(tty, ".") || !strcmp(tty, "..")) { could be insufficient. Any occurence of "." inside tty name should be evil. Above strcmp() matches exactly "." or "..", but you also want "../../" etc which should pass above check. For the ruser check, the strchr(ruser, '/') safes this, but ".." occurence may also be treatened appropriately. Sebastian
The SWAMPID for this issue is 56977. This issue was rated as moderate. Please submit fixed packages until 2014-04-24. When done, please reassign the bug to security-team@suse.de. Patchinfo will be handled by security team.
reassigning to security-team
released
Update released for: pam, pam-32bit, pam-64bit, pam-debuginfo, pam-debuginfo-32bit, pam-debuginfo-64bit, pam-debuginfo-x86, pam-debugsource, pam-devel, pam-devel-32bit, pam-devel-64bit, pam-doc, pam-x86 Products: SLE-DESKTOP 11-SP3 (i386, x86_64) SLE-SDK 11-SP3 (i386, ia64, ppc64, s390x, x86_64) SLE-SERVER 11-SP3 (i386, ia64, ppc64, s390x, x86_64) SLES4VMWARE 11-SP3 (i386, x86_64)
SUSE-SU-2014:0631-1: An update that solves one vulnerability and has one errata is now available. Category: security (moderate) Bug References: 848417,870433 CVE References: CVE-2014-2583 Sources used: SUSE Linux Enterprise Software Development Kit 11 SP3 (src): pam-1.1.5-0.12.1 SUSE Linux Enterprise Server 11 SP3 for VMware (src): pam-1.1.5-0.12.1 SUSE Linux Enterprise Server 11 SP3 (src): pam-1.1.5-0.12.1 SUSE Linux Enterprise Desktop 11 SP3 (src): pam-1.1.5-0.12.1
Guys, can SLES 11SP1 also be affected by this issue?