Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.