|
Message-ID: <87a5bqk1qs.fsf@hope.eyrie.org> Date: Thu, 16 Jan 2025 11:16:59 -0800 From: Russ Allbery <eagle@...ie.org> To: Matthias Gerstner <mgerstner@...e.de> Cc: Jacob Bachmeyer <jcb62281@...il.com>, oss-security@...ts.openwall.com Subject: Re: Re: pam-u2f: problematic PAM_IGNORE return values in pam_sm_authenticate() (CVE-2025-23013) Matthias Gerstner <mgerstner@...e.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 PAM_IGNORE. In one of my old modules (now orphaned), I see I have this piece of terrifying code: int pam_sm_authenticate(pam_handle_t *pamh UNUSED, int flags UNUSED, int argc UNUSED, const char *argv[] UNUSED) { /* * We want to return PAM_IGNORE here, but Linux PAM 0.99.7.1 (at least) * has a bug that causes PAM_IGNORE to result in authentication failure * when the module is marked [default=done]. So we return PAM_SUCCESS, * which is dangerous but works in that case. */ return PAM_SUCCESS; } 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 pam_setcred is if anything even worse than pam_authenticate. The above problem was in a module that did not want to implement authentication at all, but since it had to provide a pam_setcred implementation, was required to also implement pam_authenticate because pam_setcred 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 PAM_SUCCESS 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 pam_setcred implementation and some programs need to call pam_setcred rather than pam_open_session (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@...ie.org) <https://www.eyrie.org/~eagle/>
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.