A flaw was found in Linux-Pam in the way it handle empty passwords for non-existing users. When the user doesn't exist PAM try to authenticate with root and in the case of an empty password it successfully authenticate.

Reference: https://github.com/linux-pam/linux-pam/issues/284

Upstream patch: https://github.com/linux-pam/linux-pam/pull/300

The Linux-PAM package before 1.5.2-6.1 for openSUSE Tumbleweed allows authentication bypass for SSH logins. The pamaccess.so module doesn't correctly restrict login if a user tries to connect from an IP address that is not resolvable via DNS. In such conditions, a user with denied access to a machine can still get access. NOTE: the relevance of this issue is largely limited to openSUSE Tumbleweed and openSUSE Factory; it does not affect Linux-PAM upstream.

A flaw was found in linux-pam. The module pamnamespace may use access user-controlled paths without proper protection, allowing local users to elevate their privileges to root via multiple symlink attacks and race conditions.

The pamenv module in Linux-PAM (aka pam) 1.1.2 and earlier reads the .pamenvironment file in a user's home directory, which might allow local users to run programs with an unintended environment by executing a program that relies on the pamenv PAM check.

The module pamnamespace in linux-pam <= 1.7.0 may access user-controlled paths without proper protections, which allows a local user to elevate their privileges to root via multiple symlink attacks and race conditions.

pamnamespace.c in the pamnamespace module in Linux-PAM (aka pam) before 1.1.3 uses the environment of the invoking application or service during execution of the namespace.init script, which might allow local users to gain privileges by running a setuid program that relies on the pamnamespace PAM check, as demonstrated by the sudo program.

Integer signedness error in the pamStrTok function in libpam/pammisc.c in Linux-PAM (aka pam) 1.0.3 and earlier, when a configuration file contains non-ASCII usernames, might allow remote attackers to cause a denial of service, and might allow remote authenticated users to obtain login access with a different user's non-ASCII username, via a login attempt.

From the original report: "If SELinux is enabled, the unixrunhelperbinary function in Linux-PAM 1.1.8 and earlier hangs indefinitely when verifying a password of 65536 characters, which allows attackers to conduct username enumeration and denial of service attacks.

When supplying a password of 65536 characters or more, the process will block on the write(2) call at modules/pamunix/support.c:614 because it tries to write strlen(passwd)+1 bytes to a blocking pipe and a pipe has a limited capacity of 65536 bytes on Linux."

Acknowledgements:

Red Hat would like to thank Sebastien Macke of Trustwave SpiderLabs for reporting this issue.

Multiple directory traversal vulnerabilities in pamtimestamp.c in the pamtimestamp module for Linux-PAM (aka pam) 1.1.8 allow local users to create arbitrary files or possibly bypass authentication via a .. (dot dot) in the (1) PAMRUSER value to the getruser function or (2) PAMTTY value to the checktty function, which is used by the formattimestampname function.

linux-pam (aka Linux PAM) before 1.6.0 allows attackers to cause a denial of service (blocked login process) via mkfifo because the openat call (for protectdir) lacks ODIRECTORY.

The pamsmclosesession function in pamxauth.c in the pamxauth module in Linux-PAM (aka pam) 1.1.2 and earlier does not properly handle a failure to determine a certain target uid, which might allow local users to delete unintended files by executing a program that relies on the pamxauth PAM check.

The checkacl function in pamxauth.c in the pamxauth module in Linux-PAM (aka pam) 1.1.2 and earlier does not verify that a certain ACL file is a regular file, which might allow local users to cause a denial of service (resource consumption) via a special file.

A vulnerability was found in PAM. The secret information is stored in memory, where the attacker can trigger the victim program to execute by sending characters to its standard input (stdin). As this occurs, the attacker can train the branch predictor to execute an ROP chain speculatively. This flaw could result in leaked passwords, such as those found in /etc/shadow while performing authentications.

It was reported that pamenv and pammail 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 pammodutildroppriv / pammodutilregainpriv 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 pammail and pamenv modules in Linux-PAM before 1.1.2 did not drop privileges before accessing users' files (CVE-2010-3435, see bug #641335). Privilege dropping was added in 1.1.2, but with couple of issues pointed out by Solar Designer:

http://thread.gmane.org/gmane.comp.security.oss.general/3311/focus=3534

The code fails to switch fsgid/egid and groups (CVE-2010-3430) and does not check setfsuid() return value (CVE-2010-3431). Fix using newly-introduced pammodutildroppriv / pammodutilregainpriv 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

Stack-based buffer overflow in the assembleline function in modules/pamenv/pamenv.c in Linux-PAM (aka pam) before 1.1.5 allows local users to cause a denial of service (crash) and possibly execute arbitrary code via a long string of white spaces at the beginning of the ~/.pamenvironment file.

An issue dealing with password changes, with respect to the MINDAYS field in /etc/shadow was reported on the Debian BTS (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514437) that affects all versions of PAM 1.x. Because of this, if an administrative user sets the password minimum days via chage or passwd, /etc/shadow is updated correctly, but PAM allows the user to change their password with no regard for the MINDAYS setting, effectively allowing them to re-use old passwords immediately and disregard any established password policies that should be enforced.

This is due to the fact that no minimum age password checks are done by PAM in 1.x; in the old versions it was done in unixverifyshadow() by checking the value of of spmin. In newer PAM this check is no longer there.

A vulnerability was found in PAM. The secret is in memory, while the attacker can trigger the victim program to execute by sending characters to its stdin. In-between, they then train the branch predictor to speculatively execute a ROP chain.

Moreover, when stdin is a pipe or file, the FILE IO buffer malloc'd will receive the just-freed IO buffer that was used to read /etc/shadow, so it is also possible to have the secret conveniently available in the uninitialized memory of the stdin's FILE buf.=20

This makes several registers reference the /etc/shadow contents during the read-loop of the fgets call that the polkit agent uses in the pam conversation.=20

The attack is difficult to pull of: - Attacker needs to find a gadget chain in the mapped-in executable memory of the victim - Attacker needs to trigger TLB entries to be prefetched to win the race and fit the transient operations in the misspeculation window. - Attacker needs to tweak the attack to break ASLR. This they also can do using Spectre as well.

From the original report: "If SELinux is enabled, the unixrunhelperbinary function in Linux-PAM 1.1.8 and earlier hangs indefinitely when verifying a password of 65536 characters, which allows attackers to conduct username enumeration and denial of service attacks.

When supplying a password of 65536 characters or more, the process will block on the write(2) call at modules/pamunix/support.c:614 because it tries to write strlen(passwd)+1 bytes to a blocking pipe and a pipe has a limited capacity of 65536 bytes on Linux."

Acknowledgements:

Red Hat would like to thank Sebastien Macke of Trustwave SpiderLabs for reporting this issue.

Tim Brown reported [1] a minor security flaw in pamxauth where the runcoprocess() function, which is responsible for running 'xauth nlist' as the existing user and 'xauth merge' as the target user does not check the return code on the setuid() call. An attacker with the ability to manipulate the number of processes running on the target account can cause RLIMITNPROC to be breached when runcoprocess() is called to execute 'xauth merge' as the target user.

This issue was assigned the name CVE-2010-3316 [2] and is corrected in Linux-PAM 1.1.2 [3].

It is not believed to be exploitable on current kernels, at least not via RLIMITNPROC [4].

[1] https://sourceforge.net/tracker/?func=detail&aid=3028213&groupid=6663&atid=106663 [2] http://www.openwall.com/lists/oss-security/2010/09/24/2 [3] http://git.altlinux.org/people/ldv/packages/?p=pam.git;a=commitdiff;h=06f882f30092a39a1db867c9744b2ca8d60e4ad6 [4] http://www.openwall.com/lists/oss-security/2010/09/21/11

The pammail and pamenv modules in Linux-PAM before 1.1.2 did not drop privileges before accessing users' files (CVE-2010-3435, see bug #641335). Privilege dropping was added in 1.1.2, but with couple of issues pointed out by Solar Designer:

http://thread.gmane.org/gmane.comp.security.oss.general/3311/focus=3534

The code fails to switch fsgid/egid and groups (CVE-2010-3430) and does not check setfsuid() return value (CVE-2010-3431). Fix using newly-introduced pammodutildroppriv / pammodutilregainpriv 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

The runcoprocess function in pamxauth.c in the pamxauth module in Linux-PAM (aka pam) before 1.1.2 does not check the return values of the setuid, setgid, and setgroups system calls, which might allow local users to read arbitrary files by executing a program that relies on the pamxauth PAM check.

The expandarg function in the pamenv module (modules/pamenv/pamenv.c) in Linux-PAM (aka pam) before 1.1.5 does not properly handle when environment variable expansion can overflow, which allows local users to cause a denial of service (CPU consumption).

The privilege-dropping implementation in the (1) pamenv and (2) pammail modules in Linux-PAM (aka pam) 1.1.2 does not check the return value of the setfsuid system call, which might allow local users to obtain sensitive information by leveraging an unintended uid, as demonstrated by a symlink attack on the .pamenvironment file in a user's home directory. NOTE: this vulnerability exists because of an incomplete fix for CVE-2010-3435.

It was found that in pamuserdb module for PAM, password hashes weren't compared case-sensitively, which could lead to acceptance of hashes for completely different passwords, which shouldn't be accepted.

After hashing the user's password with crypt(), pamuserdb compares the result to the stored hash case-insensitively with strncasecmp(), which should be avoided, as it could result in an increased possibility of a successful brute-force attack.

References: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731368

It was reported that pamenv and pammail 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 pammodutildroppriv / pammodutilregainpriv 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.

On Tue, Oct 08, 2024 at 08:10:17AM +0200, Simon Josefsson wrote: I noticed that that there are Linux-PAM helpers to drop privileges:

https://github.com/linux-pam/linux-pam/blob/master/libpam/pammodutilpriv.c#L52 This currently switches fsuid/fsgid (so for the current thread only), but uses initgroups() and setgroups() libc functions (so affects all threads). Code last modified 4 years ago, which pre-dates our recognition of the supplementary groups vs. threads problem and its fix in tcb. Maybe Linux-PAM should implement a similar change now. I have found another implementation of this in yubico-pam:

https://github.com/Yubico/yubico-pam/blob/master/dropprivs.c This currently switches euid/egid/groups, so doesn't try to be MT-safe.

(On Linux, it is also possible to switch euid/egid via direct syscalls for the current thread only, but there's no point because switching of fsuid/fsgid is more appropriate for this purpose anyway.)

A couple of nitpicks on your upstream oath-toolkit code:

1. You restore egid/euid in this same order as you set them. This unnecessarily introduces an extra temporary state. I suggest that you restore them in reverse order, so set egid/euid ... restore euid/egid. (The SUSE patch doesn't have this "problem".)

2. After uses of asprintf() you first check the pointer for NULL and only then check the return value. Strictly speaking, this is undefined behavior because the pointer may be uninitialized if the return value indicates an error. Of course, this shouldn't matter in practice unless a compiler is aware and deliberately exploits the UB (e.g. optimize everything out because this is UB anyway) or the environment (hardware or a software "sanitizer") is such that uninitialized reads are trapped, but to make it correct I suggest that you simply drop the NULL checks. Btw, do you have any thoughts on WHICH user to drop privileges to? The SUSE patch drops privs to the credential file owner. My patch drops privs to the PAM user that is being authenticated. I think there are reasonable arguments for both choices, and for all reasonable configurations that I'm aware of, I don't think the choice matters. Thank you for bringing this up.

I think that for reasonable configurations in absence of attacks this difference is unimportant, however there are different risks involved.

In particular, I worry that the SUSE approach could be susceptible to hard link attacks (when the fs.protectedhardlinks sysctl is not set). Would this allow to overwrite someone else's file (the original issue) if the user can hard link that file? I currently don't see why not, so it's probably a vulnerability.

Would it allow to have the log in process temporarily switch to another user (of the attacker's choosing)? This sounds relatively minor.

In general, switching to a user not only drops privileges for file access, but also potentially exposes the process as that user's. fsuid/fsgid switching is the safest in this respect (these were meant just for file access purposes), but with other IDs (depending on which) there may be extra exposure of the partially privileged log in process to the user via /proc, kill(), setpriority(), etc. ... but thankfully and hopefully not also via ptrace() on modern systems anymore.

Alexander

Hi Jacob,

On Wed, Jan 15, 2025 at 11:58:00PM -0600, Jacob Bachmeyer wrote: On 1/15/25 06:03, Matthias Gerstner wrote: There exist utility modules that don't actually authenticate but perform helper functions or enforce policy. An example is the pamfaillock [8] module, which can be added to the auth management group to record failed authentication attempts and lock the account for a certain time if too many failed attempts occur. This module will return PAMSUCCESS when running in "preauth" mode and if the maximum number of failed attempts has not been reached yet. In such a case PAMSUCCESS would become the overall authentication result when pam-u2f returns PAMIGNORE. This looks to me like a logic error in PAM.  Why are utility modules that do not actually perform authentication returning PAMSUCCESS (indicating successful authentication(!)) instead of PAMIGNORE or some other "neutral" code?

Is this a widespread misconfiguration? I suppose libpam has no way of differentiating the "importance" or purpose of the modules it runs. It could be argued that such utility modules that don't actually authenticate should indeed not return PAMSUCCESS. From my experience PAM module implementations generally return PAMSUCCESS, though, if they deem their task successfully completed. This makes sense from a single module's point of view, naturally.

I could not find anything conclusive about this topic in the PAM documentation and development guides. Actually not even about the exact behavior and purpose of PAMIGNORE.

For hardening purposes it could be a good idea to return something like PAMIGNORE in utility modules that implement pamsmauthenticate(). I'm not sure if I'm overlooking something here that might spoil the idea, however. This is a discussion that could be continued on a PAM development mailing list (but I couldn't find one after a quick search). Is there a keyword that causes PAM to treat failure as failure but ignore PAMSUCCESS that should be used with those utility modules? It looks like there is no keyword that feels natural for this purpose. Technically it could be done using the extended PAM syntax in a way like this:

auth [success=ignore ignore=ignore default=bad] pammyutility.so [...]

So it could be handled on configuration level, but it would complicate the often already pretty complex PAM stacks we see on Linux distributions.

Cheers

Matthias

Matthias Gerstner wrote in <Z4jejSMgNUpzFI6T () kasco suse de>: |On Wed, Jan 15, 2025 at 11:58:00PM -0600, Jacob Bachmeyer wrote: |> On 1/15/25 06:03, Matthias Gerstner wrote: |>> There exist utility modules that don't ... |> This looks to me like a logic error in PAM.  Why are utility modules ... |I suppose libpam has no way of differentiating the "importance" or |purpose of the modules it runs. It could be argued that such utility

PAM is also massively underdocumented regarding things like id handling, environmental status in which modules run, that sessions can be escaped via simple daemonization (not that it matters to pam at all that mechanisms exist to overcome this, ie, on whatever result / status code / xy side), and similar things.

For example that PAMUSER can return NULL or an empty string in the PAMSUCCESS status code case is more than just astonishing to the occasional programmer who would expect that "sane behaviour" also depends on some context, here not making sense on POSIX?

Also system(3) should be a pretty much safe system call if a session opener program uses it, in that environmental attack surface could only come from system side aka first level administrator configuration, unless i am very much mistaken. Ie RFC 86 writes

Authentication software deserves special attention because authentication forms a very critical component of any secure computer system.

and for session-in-session, for example su(1), we read

The current environment is passed to the new shell. The value of $PATH is reset to /bin:/usr/bin for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the superuser. This may be changed with the ENVPATH and ENVSUPATH definitions in /etc/login.defs.

There is no notion of signal handling, and i blindly assume that PAM takes care for closing sessions with that "set right". (not ducking.)

Unfortunately my pamxdg (not what became the same in FreeBSD) that used it never was brought up in public. I finally unrolled the system(3) with fork(2)/execve(2), but there is possibility left since i still do not care for signals therein.

... |the often already pretty complex PAM stacks we see on Linux |distributions. ...

Really, in my opinion someone with money (some summer of code maybe) should iterate PAM, so that certain conditions are in a defined state for running module code, and that mode should be addressible so that mode<>module is locked (ie module code only runs if right mode). Maybe via some dlopen(3) availability check, and when run it returns a flag mask of states is preassumes, or something.

--End of <Z4jejSMgNUpzFI6T () kasco suse de>

Just my one cent.

--steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | |In Fall and Winter, feel "The Dropbear Bard"s pint(er). | |The banded bear |without a care, |Banged on himself for e'er and e'er | |Farewell, dear collar bear

Matthias Gerstner <mgerstner () suse de> writes: I could not find anything conclusive about this topic in the PAM documentation and development guides. Actually not even about the exact behavior and purpose of PAMIGNORE. In one of my old modules (now orphaned), I see I have this piece of terrifying code:

int pamsmauthenticate(pamhandlet pamh UNUSED, int flags UNUSED, int argc UNUSED, const char argv[] UNUSED) { / We want to return PAMIGNORE here, but Linux PAM 0.99.7.1 (at least) has a bug that causes PAMIGNORE to result in authentication failure when the module is marked [default=done]. So we return PAMSUCCESS, which is dangerous but works in that case. / return PAMSUCCESS; }

This has been a long-standing problem, and it would be great to get it sorted out somehow and clearly documented and to try to signal to all PAM modules that they can drop bug workarounds like this.

The situation with expected return statuses and behavior of pamsetcred is if anything even worse than pamauthenticate. The above problem was in a module that did not want to implement authentication at all, but since it had to provide a pamsetcred implementation, was required to also implement pamauthenticate because pamsetcred otherwise wasn't called. In this case, this was specifically called out in the documentation:

Note that this is not an authentication module and will always return PAMSUCCESS to any authentication attempt, so never make this module sufficient in your authentication stack. It's only listed as an auth module because it provides a pamsetcred implementation and some programs need to call pamsetcred rather than pamopensession (screen savers, for instance, to refresh credentials).

But of course who knows if anyone reads the documentation.

My experience as a PAM module maintainer is that I kept making educated guesses then iterating if I got a bug report, which for a security-sensitive piece of software is not a comfortable place to be. It's a recipe for erring on the side of failing open, which is the opposite of what should be happening, but one tends to only get bug reports when logins fail.

-- Russ Allbery (eagle () eyrie org) <https://www.eyrie.org/~eagle/>