auth-pam: don't leak PAM env strings after pam_putenv()
Simon Josefsson
simon at josefsson.org
Tue May 19 04:20:45 AEST 2026
Avinash Duduskar <avinash.duduskar at gmail.com> writes:
> Source reads on the three you named:
>
> Linux-PAM: libpam/pam_env.c strdups namevalue on entry.
> OpenPAM: lib/libpam/pam_putenv.c lines 73, 91 strdup.
> illumos: usr/src/lib/libpam/pam_framework.c lines 1366-1478
> splits namevalue into local name and value, strdups
> copies into the handle, frees the locals; the input
> is never retained.
That's a nice analysis. Did you consider older versions? Maybe the
contract wrt strdup changed over the years depending on implementation.
PAM is a gift that keeps on giving.
/Simon
> Oracle Solaris source isn't public. The pam_putenv(3PAM) man
> page is silent on ownership. illumos is the 2010 fork of the
> same Sun PAM, which makes this strong but not conclusive
> evidence for current Solaris.
>
> AIX PAM is also closed. IBM's pam_putenv(3) documentation
> (ibm.com/docs/en/aix/7.3.0?topic=p-pam-putenv-subroutine)
> describes behaviour but does not commit on ownership semantics.
> HP-UX 11 is flagged Sun-derived in OpenSSH's configure.ac
> (PAM_SUN_CODEBASE), implying the same contract carries.
>
> XSSO itself doesn't commit on ownership; the contract is
> implementation-defined.
>
> v2 will gate the free() under !defined(_AIX), per your #ifdef
> suggestion. That covers the three libraries you named and
> preserves the conservative leak on the one implementation
> I couldn't verify from public sources.
>
> On Mon, 2026-05-18 at 10:36 -0600, Theo de Raadt wrote:
>> If we knew for sure, this is a place #ifdef could be used.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1251 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20260518/5918d7bb/attachment.asc>
More information about the openssh-unix-dev
mailing list