[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250116162521.wJ5wghpL@steffen%sdaoden.eu>
Date: Thu, 16 Jan 2025 17:25:21 +0100
From: Steffen Nurpmeso <steffen@...oden.eu>
To: oss-security@...ts.openwall.com
Subject: Re: pam-u2f: problematic PAM_IGNORE return
values in pam_sm_authenticate() (CVE-2025-23013)
Matthias Gerstner wrote in
<Z4jejSMgNUpzFI6T@...co.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 PAM_USER can return NULL or an empty string in
the PAM_SUCCESS 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 ENV_PATH and ENV_SUPATH 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 pam_xdg (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@...co.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
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.
