It was reported that pam_env and pam_mail modules do not drop privileges before accessing users' files. This flaw can lead to information disclosure. Issue was partially addressed in Linux-PAM 1.1.2: http://git.altlinux.org/people/ldv/packages/?p=pam.git;a=commitdiff;h=06f882f30092a39a1db867c9744b2ca8d60e4ad6 The fix in 1.1.2 has some problems though, it fails to switch fsgid/egid and groups (CVE-2010-3430) and does not check setfsuid() return value (CVE-2010-3431): http://thread.gmane.org/gmane.comp.security.oss.general/3311/focus=3551 Fix using newly-introduced pam_modutil_drop_priv / pam_modutil_regain_priv was committed in upstream CVS and should be included in 1.1.3: http://git.altlinux.org/people/ldv/packages/?p=pam.git;a=commitdiff;h=843807a3a90f52e7538be756616510730a24739a Acknowledgements: Red Hat would like to thank Sebastian Krahmer of the SuSE Security Team for reporting this issue.
The impact here depends on the affected module and PAM version. pam_mail supports checking mbox or Maildir format mailboxes for new mail. By default, pam_mail checks mailboxes with path /var/mail/<username>. This module does not open mailbox files, only performs following checks: - for mbox, checks if atime < mtime - for Maildir, checks if there are any files under new/ and cur/ directories The information that can be leaked via this flaw is limited to knowing whether some file has more recent modification time than access time, or whether some directory is empty. In Red Hat Enterprise Linux, pam_mail is not used by default. Additionally, default /var/mail permissions do not allow non-privileged to create files in that directory (and hence replace their mailbox with symlink to file or directory for which they want to get the info mentioned above). This can only affect non-default configurations where pam_mail is configured for some service and either /var/mail permissions are changed, or alternative mailbox path is configured (via pam_mail's dir option). pam_env issue is related to user_envfile (~/.pam_environment by default) support. This was introduced in Linux-PAM 1.0.90, it is not supported in PAM versions in Red Hat Enterprise Linux 3, 4, and 5. User can exploit this flaw by symliking ~/.pam_environment to some other file that should be read by pam_env with root privileges and log in to the system. Lines of the file that have expected KEY=VALUE form are made available to user via environment. Conveniently for attacker, pam_env skips (with syslog message) all malformed lines, so it can be used to extract value even from files that do not have all lines with expected format. Possible targets are shell scripts with hard-coded passwords (e.g. various backup scripts), or various INI file format configuration files (such as MySQL's my.cnf, that can contain database password; however, pam_env does not tolerate spaces around '=', which may be allowed in those INI files).
Referenced discussion on these PAM issues also points out that pam_env's intended behaviour of reading ~/.pam_environment is security risk that may lead to environment changes unexpected to the system administrator, service calling PAM, or subsequently consulted PAM modules: http://thread.gmane.org/gmane.comp.security.oss.general/3311/focus=3562 pam_env does not directly change programs environment and only does changes to the environment associated with pam handle. Application can later retrieve pam's environment via pam_getenvlist and export changes to its environment. Other PAM modules can be affected if they use pam_getenv. Given the default use of pam_env for multiple, shall we consider changing pam_env's user_readenv option default value to off?
(In reply to comment #3) > Given the default use of pam_env for multiple, shall we consider changing > pam_env's user_readenv option default value to off? Commit changing user_readenv default upstream: http://pam.cvs.sourceforge.net/viewvc/pam/Linux-PAM/modules/pam_env/pam_env.c?r1=1.22&r2=1.23 http://pam.cvs.sourceforge.net/viewvc/pam/Linux-PAM/modules/pam_env/pam_env.8.xml?r1=1.7&r2=1.8
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2010:0819 https://rhn.redhat.com/errata/RHSA-2010-0819.html
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2010:0891 https://rhn.redhat.com/errata/RHSA-2010-0891.html
(In reply to comment #1) > User can exploit this flaw by symliking ~/.pam_environment to some other file > that should be read by pam_env with root privileges and log in to the system. > Lines of the file that have expected KEY=VALUE form are made available to user > via environment. Conveniently for attacker, pam_env skips (with syslog > message) all malformed lines, so it can be used to extract value even from > files that do not have all lines with expected format. Possible targets are > shell scripts with hard-coded passwords (e.g. various backup scripts), or > various INI file format configuration files (such as MySQL's my.cnf, that can > contain database password; however, pam_env does not tolerate spaces around > '=', which may be allowed in those INI files). Following write-up covers another interesting attack vector, where this flaw is used to extract part of the SSH DSA private key, sufficiently large to compute the rest of the private key in a fairly short time: http://7bits.nl/projects/pamenv-dsakeys/pamenv-dsakeys.html