--- Begin Message ---
Version: 1:9.7p1-6
On Sun, 14 Sep 2014 at 23:46:58 +0200, Jakub Wilk wrote:
A few years ago CVE-2010-4708 was assigned to pam:
The pam_env module in Linux-PAM (aka pam) 1.1.2 and earlier reads
the .pam_environment file in a user's home directory, which might
allow local users to run programs with an unintended environment by
executing a program that relies on the pam_env PAM check.
This was fixed in pam by disabling user_readenv by default.
However, sshd.pam explicitly sets user_readenv=1.
This is no longer the case in trixie/sid or the upcoming Debian 13
release, as a result of:
openssh (1:9.7p1-6) unstable; urgency=medium
* Stop reading ~/.pam_environment, which has a history of security
problems and is deprecated by PAM upstream (closes: #1018260).
-- Colin Watson <cjwatson@debian.org> Tue, 25 Jun 2024 14:20:44 +0100
(It is still the case in Debian 12 'bookworm'.)
This is a non-backward-compatible change, flagged in the release notes
as
<https://www.debian.org/releases/testing/release-notes/issues.en.html#openssh-server-no-longer-reads-pam-environment>.
I suspect that the openssh maintainers and security team would be
reluctant to backport this change to Debian 12 unless there is a
practical exploit (but I'm not an openssh maintainer or the security
team, so I could be wrong).
If you are aware of a practical exploit, please contact the security
team privately (not via bugs.debian.org).
user_readenv=1 might allow bypassing access restrictions (such as user
shell set to /usr/bin/rssh) even when PermitUserEnvironment is
disabled.
In the past the security impact of this setting was always rather vague
("might allow local users to run programs with an unintended
environment", "might allow bypassing access restrictions"), because...
On Sun, 05 May 2024 at 20:36:49 +0100, Max Bowsher wrote:
One further surprise: whilst the nomenclature tends to lead people in the
direction of believing ~/.pam_environment is a user addition to /etc/
environment, it is not, it is actually a user addition to /etc/security/
pam_env.conf. I am uncertain if this was originally intended, or was a historic
coding error normalized by time. Previous versions of the man page text hint at
the latter - [3]https://github.com/linux-pam/linux-pam/issues/6.
... the documentation has a tendency to conflate the "PAM environment"
with the environ(7) that will be given to the final program that gets
exec'd by the entry-point service (in this case, the user's shell or
other command that is being run via ssh).
An impact of this that was not necessarily obvious in the past is that
the environment variables set by pam_env do not only affect the exec'd
program; they can also be taken as input by other PAM modules, such as
pam_systemd, which in some cases assume that they are trusted (for
example pam_systemd takes the XDG_SESSION_ID from the PAM environment,
and I don't know whether there is another way in which it could get this
information). See §(Digression) in the CVE-2025-6018/CVE-2025-6019
advisory reported at
<https://marc.info/?l=oss-security&m=175019049328531&w=2> for more
details.
smcv
--- End Message ---