PAM 0.76 treats a disabled password as if it were an empty (null) password, which allows local and remote attackers to gain privileges as disabled users.

A flaw was found in pamaccess, where certain rules in its configuration file are mistakenly treated as hostnames. This vulnerability allows attackers to trick the system by pretending to be a trusted hostname, gaining unauthorized access. This issue poses a risk for systems that rely on this feature to control who can access certain services or terminals.

Linux PAM modules allow local users to gain root access using temporary files.

The SELinux version of PAM before 0.78 r3 allows local users to perform brute force password guessing attacks via unixchkpwd, which does not log failed guesses or delay its responses.

A security flaw was found in PAM pamkrb5 module, providing user authentication based on Kerberos principals. A remote attacker could use this flaw to recognize, if some username/login belongs to set of user accounts, existing on the system, and subsequently perform dictionary based password guess attack.

On Thu, Oct 17, 2024 at 10:28:41AM +0200, Matthias Gerstner wrote: - setgroups() is invoked to drop supplementary group membership. Looks good to me. - the usersfile is checked for additional hard-links; if the link count is larger than one, then the file is rejected. This prevents possible hard link attacks on the end of the unprivileged user. There's a subtle issue here - another user's (or root's) temporary file may be hard-linked and stnlink may be back to 1 after the file is unlinked by its original creator/user. For example, tmpfile(3) unlinks the file right away, yet the calling program is expected to proceed to use it. In that case, an attacker winning the race could manipulate content of another user's temporary file, which that user's program could then read back and use. With the Linux kernel sysctl protectedhardlinks set to 1 (the usual default on most distributions), this attack will not work either way. Right. In our case it is only a check of stnlink. This is because we are dropping privileges to the owner of the file. If one would drop privileges to the to-be-authenticated user, then a check of stuid would be in order as well. Right. It appears that given your decision to allow any file owner, you cannot fully prevent hard link attacks without protectedhardlinks. - ONOCTTY has been added to the open() call of the usersfile. This makes this aspect explicit, although the code already checks that the file is a regular file, so the situation shouldn't arise in the first place. Oh, I had thought you'd only be able to reliably post-check for regular file, which would be too late against side-effects on open(). However, now I realize that you first open with OPATH, which presumably avoids side-effects(), then check fstat(), and only then if everything looks good you reopen via /proc/self/fd/fd for actual usage. That's quite a hack, but yes, ONOCTTY on reopen should be redundant.

() The man page says "Opening a file or directory with the OPATH flag requires no permissions on the object itself", so we'd have bigger problems regardless of your usage if there were side-effects. The reason why we accept different ownership of the file is for increased backward compatibility. The usersfile feature in pam-oath allows for potentially complex scenarios regarding to the ownership of the file and it was not previously clearly specified which scenarios are supported. When only supporting the simple scenario of the usersfile being located directly beneath the to-be-authenticated user's home directory, then a lot of things become simpler, as it has been done in the upstream approach in a couple of aspects. OK, this makes sense.

Alexander

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.

-- Jacob

On 2/6/25 08:55, Matthias Gerstner wrote: [...]

On the use of PAMSUCCESS ---------------------------

PAM modules that only serve utility functions but do not actually authenticate could consider not returning PAMSUCCESS but PAMIGNORE instead. This would avoid unintended successful authentication in a situation like described in this report. It seems natural to PAM module authors to return PAMSUCCESS if nothing in their module failed, however. A lot of modules work this way and changing them all would be a big effort.

-- Jacob