Bug 958338 (CVE-2025-6018) – <sys-libs/pam-1.4.0: Local privilege escalation via pam_env with non-default configuration

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description Sam James 2025-06-18 03:49:17 UTC]

"""
========================================================================
CVE-2025-6018: LPE from unprivileged to allow_active in *SUSE 15's PAM
========================================================================

________________________________________________________________________

Analysis
________________________________________________________________________

During our recent work on OpenSSH, we noticed that, when an unprivileged
user logs in via sshd on openSUSE Leap 15 or SUSE Linux Enterprise 15:

- PAM's pam_env module (from Linux-PAM 1.3.0) reads this user's
  ~/.pam_environment file by default (i.e., pam_env's "user_readenv"
  configuration option is 1 by default);

- the pam_env module is called first, by sshd's do_pam_setcred(), as
  part of PAM's "auth" stack (from /etc/pam.d/common-auth);

- the pam_systemd module is called later, by sshd's do_pam_session(), as
  part of PAM's "session" stack (from /etc/pam.d/common-session).

Consequently, an unprivileged attacker who logs in via sshd can force
the pam_env module to add arbitrary variables to PAM's environment (by
first writing them to ~/.pam_environment), and these variables are then
returned to the pam_systemd module by pam_getenv(). In particular, the
pam_systemd module calls pam_getenv() for the XDG_SEAT and XDG_VTNR
variables, which immediately reminded us of Jann Horn's excellent
CVE-2019-3842 in systemd:

  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1812316

In a nutshell, by setting XDG_SEAT=seat0 and XDG_VTNR=1 in
~/.pam_environment, an unprivileged attacker who logs in via sshd on
openSUSE Leap 15 or SUSE Linux Enterprise 15 can pretend that they are,
in fact, a physical user who is sitting in front of the computer; i.e.,
an "allow_active" user, in polkit parlance.
[...]
"""

[Comment 1 Sam James 2025-06-18 03:53:22 UTC]

Note that we don't deviate from upstream defaults wrt pam_env, so Gentoo installs aren't affected by this unless:
1) an old version of sys-libs/pam is installed (the default changed in https://github.com/linux-pam/linux-pam/commit/f83fb5f25263356391d71da595def409e8dd90f7 upstream, which is in >=1.4.0), or
2) the user has set `user_readenv` themselves to enable it

With regard to 1), we've issued not one but two GLSAs since 1.4.0: bug 756361 and bug 922397 / bug 942075.

With regard to 2), maybe we're not so worried about that, given there's many ways you can inflict issues on yourself by changing settings without reading documentation.

I'm inclined to say there's nothing for us to do here.

[Comment 2 Larry the Git Cow 2025-06-18 04:34:02 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ce989574f5a86618ea4c389c9e1810c03c8b6a5e

commit ce989574f5a86618ea4c389c9e1810c03c8b6a5e
Author:     Sam James <[e-mail]>
AuthorDate: 2025-06-18 04:32:14 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2025-06-18 04:33:24 +0000

    sys-fs/udisks: patch CVE-2025-6019
    
    Depend on a fixed version of libblockdev too.
    
    Bug: https://bugs.gentoo.org/958338
    Bug: https://bugs.gentoo.org/958339
    Signed-off-by: Sam James <[e-mail]>

 .../udisks/files/udisks-2.10.1-CVE-2025-6019.patch |  43 ++++++
 sys-fs/udisks/udisks-2.10.1-r4.ebuild              | 149 +++++++++++++++++++++
 2 files changed, 192 insertions(+)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=16072fc78769f65e1a5af36aefeaf4f88f4aefb1

commit 16072fc78769f65e1a5af36aefeaf4f88f4aefb1
Author:     Sam James <[e-mail]>
AuthorDate: 2025-06-18 04:28:43 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2025-06-18 04:33:18 +0000

    sys-libs/libblockdev: patch CVE-2025-6019
    
    Quoting myself on the bug:
    > This is from https://www.openwall.com/lists/oss-security/2025/06/17/4 but
    > it's a little complicated in that it relies on a privilege escalation bug
    > from unprivileged -> polkit 'allow_active' (bug 958338) that we aren't
    > affected by.
    >
    > But nonetheless, supposing such another such LPE exists, this could form
    > part of a chain from 'allow_active' -> root, so it still matters.
    
    My intention is not to rush stabling 3.3.0 as just bumped to it (that
    commit bumping to 3.3.0 lands in the same push as this) and we were
    a bit behind before so want to give a little bit of time for any regressions
    to be reported. Combined with the above, we don't need to hurry s.t. we do
    it with no time in ~arch at all.
    
    Bug: https://bugs.gentoo.org/958338
    Bug: https://bugs.gentoo.org/958339
    Signed-off-by: Sam James <[e-mail]>

 .../files/libblockdev-3.3.0-CVE-2025-6019.patch    | 24 ++++++++++++++++++++++
 sys-libs/libblockdev/libblockdev-3.3.0.ebuild      |  1 +
 2 files changed, 25 insertions(+)