Sebastian Krahmer reported [1] a path traversal issue in pam_timestamp's format_timestamp_name(): "" 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. "" [1] http://seclists.org/oss-sec/2014/q1/645
I would say that the impact is very low as manipulation of PAM_TTY and/or PAM_RUSER is not easily possible in general.
MITRE assigned CVE-2014-2583 to the path traversal issue: http://seclists.org/oss-sec/2014/q1/664
Upstream commit: https://git.fedorahosted.org/cgit/linux-pam.git/commit/?id=9dcead87e6d7f66d34e7a56d11a30daca367dffb
Upstream bug: https://fedorahosted.org/linux-pam/ticket/27
There are multiple factors that limit impact of this issue. It only makes sense to use this module in PAM configuration for local services. Unlike remote services, PAM_RUSER, PAM_USER and PAM_TTY are unlikely to get set to an arbitrary value specified by user, but are rather set to name of a local user attempting to run some command with elevated privileges, name of a target user or a user to authenticate as, and invoking user's current terminal. Hence PAM_*USER values are expected to match user names as defined in password database (/etc/passwd) - PAM_RUSER matching name of the user invoking command, and PAM_USER is typically "root". TTY is expected to match local terminal device name. If PAM_TTY value contains '/', pam_timestamp only uses the part after the last '/' when generating time stamp file name. Therefore, PAM_TTY is not very useful for directory traversal attacks. The most interesting value that can be used as part of the time stamp file name is "..". There are two possible time stamp file name formats: - timestamp_dir/ruser/tty:user - This is the typical case, used when PAM_RUSER != PAM_USER - timestamp_dir/ruser/tty - This is used when PAM_RUSER == PAM_USER, such configuration is lot less common though. In the former case, there is no traversal, as :user is appended to "..", resulting in pam_timestamp using file name "..:user". In the latter case, file name points to timestamp_dir/ruser directory, which will not be used by pam_timestamp, which checks whether time stamp file used is regular file. The pam_timestamp also uses additional protection for its time stamp files. The content of a time stamp file includes: full file path, time stamp and HMAC (a keyed hash message authentication code) generated using SHA-1. The key used is a random 64 byte value stored in a file only accessible to root. Hence even if a service using pam_timestamp allows user to set arbitrary PAM_RUSER value, attacker would need to pass HMAC check by guessing the key value (unlikely) or getting the value via some other flaw. In Red Hat Enterprise Linux, the pam_timestamp module is used in the default configuration for various utilities, typically configuration tools (such as various system-config-* tools). These services use consolehelper / userhelper, which sets following PAM items: - PAM_RUSER - Set to user name of the invoking user. - PAM_USER - Set to user set as USER in /etc/security/console.apps/* configuration file, or invoking user name if USER setting is "<user>" - PAM_TTY - Not set in Red Hat Enterprise Linux 5. In Red Hat Enterprise Linux 6, it's set to a value based on what is returned by ttyname() if standard input is attached to terminal, otherwise not set. If PAM_TTY is not set, pam_timestamp uses value returned by ttyname() or hardcoded string "unknown". The above values are under system administrator's control. Therefore, this issue has no practical impact on default or typical Red Hat Enterprise Linux configurations.
Statement: This issue affects the versions of pam as shipped with Red Hat Enterprise Linux 5 and 6. Red Hat Security Response Team has rated this issue as having Moderate security impact. A future update may address this issue. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.
pam-1.1.8-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2014-2583