""" ======================================================================== 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. [...] """
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.
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 <sam@gentoo.org> AuthorDate: 2025-06-18 04:32:14 +0000 Commit: Sam James <sam@gentoo.org> 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 <sam@gentoo.org> .../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 <sam@gentoo.org> AuthorDate: 2025-06-18 04:28:43 +0000 Commit: Sam James <sam@gentoo.org> 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 <sam@gentoo.org> .../files/libblockdev-3.3.0-CVE-2025-6019.patch | 24 ++++++++++++++++++++++ sys-libs/libblockdev/libblockdev-3.3.0.ebuild | 1 + 2 files changed, 25 insertions(+)
