[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5124504d-3d37-42ad-8bf7-fbbb7f8d0317@gmail.com>
Date: Wed, 15 Jan 2025 23:58:00 -0600
From: Jacob Bachmeyer <jcb62281@...il.com>
To: oss-security@...ts.openwall.com, Matthias Gerstner <mgerstner@...e.de>
Subject: Re: pam-u2f: problematic PAM_IGNORE return values in
pam_sm_authenticate() (CVE-2025-23013)
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 pam_faillock [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 `PAM_SUCCESS` when running in "preauth" mode and
> if the maximum number of failed attempts has not been reached yet. In
> such a case `PAM_SUCCESS` would become the overall authentication result
> when pam-u2f returns `PAM_IGNORE`.
This looks to me like a logic error in PAM. Why are utility modules
that do not actually perform authentication returning PAM_SUCCESS
(indicating successful authentication(!)) instead of PAM_IGNORE or some
other "neutral" code?
Is this a widespread misconfiguration? Is there a keyword that causes
PAM to treat failure as failure but ignore PAM_SUCCESS that should be
used with those utility modules?
-- Jacob
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.
