Only non patched issue left about pam_env user_readenv is that
.pam_environment change the pam_handle environment of the later root
running PAM modules from a user controlled file and not being last in
the PAM loaded modules it change the environment these other modules
have (inclduign any that run as root).
Though I wonder if it is a security issue. I mean do these other
modules even read this pam_handle environment? THe Fedora patch to turn
off user_readenv by default was talking only about subsequent modules
in the PAM stack only (and was maintained by the upstream developer if
I understood correctly).
pam_env does not directly change programs environment and only does
changes to the environment associated with pam handle. Application can
later retrieve pam's environment via pam_getenvlist and export changes
to its environment. Other PAM modules can be affected if they use
pam_getenv.
also wouldn't running pam_env last in PAM session file workaround this
issue if any
(though at least on Debian common-password PAM modules run after the
session ones)
Maybe the issue is the fact that pam_env setup a separate env that
could be applied to programs asynchronously.
Note that the CVE tells about program not PAM module.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4708 "
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. "
I do not see the difference between changing the environment as a user
via $HOME/.profile or $HOME/.pam_environment.
A few years ago, I saw no other way than $HOME/.pam_environment to set
XDG_CACHE_HOME on one user session only for a Wayland session.
https://help.ubuntu.com/community/EnvironmentVariables still advertise
$HOME/.pam_environment usage
https://wiki.archlinux.org/title/Environment_variables tells that per
use system user environment variables are available systemd.
Even if $HOME/.pam_environment is deprecated, I believe
/etc/security/pam_env.conf or something alike only under system
administrator access should provide the ability to define environmet
variable for a specific user, which it does currently not allow.
GDM and KDE Plasma upstreams source systemd user environment variables
in wayland sessions.
But what about ssh,
Xorg (on Arch OK but on Debian I cannot find the
/etc/X11/xinit/xinitrc.d/50-systemd-user.sh equivalent:
https://wiki.archlinux.org/title/Systemd/User#DISPLAY_and_XAUTHORITY),
"shell" login program (was told soon in 2017
https://in.waw.pl/~zbyszek/blog/environmentd.html, I cannot find a
reference in upstream util-linux)
and other wayland session manager?
Maybe exporting in /etc/profile with "systemctl --user show-
environment" would help?
Though I agree that systemd user environment variable gracefuly cope
with the need to fulfill, there might be works left for it to apply to
all login sessions in Debian.
Alban
History:
--------------------
https://bugzilla.gnome.org/show_bug.cgi?id=736660
Ray Strode [halfline] 2015-08-13 16:06:54 UTC
(...)
<halfline> q. By default this option is off as user supplied
<halfline> environment variables in the PAM environment
could affect behavior
<halfline> of subsequent modules in the stack without the
consent of the
<halfline> system administrator.(...)
<grawity>
http://pkgs.fedoraproject.org/cgit/pam.git/tree/pam-1.1.3-nouserenv.patch
(...)
which is
https://src.fedoraproject.org/rpms/pam/blob/f30/f/pam-1.1.3-nouserenv.patch
and is now upstream since f83fb5f2 "pam_env: Change the default to not
read the user .pam_environment file", ie v1.4.0
https://github.com/linux-pam/linux-pam/commit/f83fb5f2
(it was about changing the default user_readenv to 0)
Comment 6 Ray Strode [halfline] 2015-08-13 16:39:49 UTC
(...)
<halfline> perhaps it should be in pam_systemd ...
<grawity> maybe
<grawity> I think some distros already use pam_env for the package
environment?
<halfline> yea, pam_env would be okay too, and logical
<grawity> perhaps if it wasn't so difficult to achieve the equivalent
of FOO="$HOME/bar" with it
<halfline> yea it's very strange
<halfline> it has two different file formats
<halfline> one that allows that kind of thing and one that doesn't
<grawity> and the one which does allow it appears to lack both $HOME
and $PATH sometimes
<halfline> well those things are set by gdm after the auth stack has
run
<halfline> and pam_env is run as part of the auth stack
<halfline> well in fedora anyway
<halfline> so putting "session optional pam_env.so user_readenv=1
user_envfile=.config/environment" in the very bottom of the pam file
would fix that issue
<halfline> oh i guess it wouldn't though
<halfline> since envfiles are the file format that doesn't support
substitution
<grawity> hmm its parser actually doesn't care
<grawity> so both formats work in ~/.pam_environment
<halfline> oh interesting, didn't know that
<grawity> it's a rather weird module
<halfline> yea so just making it a session module instead of (or in
addition to) and auth module would fix the issue i guess
<halfline> but if we could get systemd to do it, then we could maybe
cleave ourselves away from pam_env and it's oddities
(...)
Comment 7 Ray Strode [halfline] 2015-08-13 18:20:43 UTC
(...)
<owen> halfline: it sounds like the reading of environment variables in
pam is at the "wrong time"
<halfline> well pam_env is currently done first thing before all the
other modules
<halfline> so it can set up the system environment for them
<halfline> there's nothing that would prevent us for adding it at the
very bottom too, for user environment
<owen> halfline: it seems like the fedora patch is saying that for that
reason having user environment variables set then is bad
<halfline> exactly
<halfline> which i totally agree with
<halfline> since pam modules run as root
(...)
<halfline> it's also wrong for a different reason... we don't know the
username (necessarily) until auth completes
<halfline> since it's valid to have the final username be different
than what the user typed originally
<halfline> and likewise the home directory won't necessarily be known
<halfline> or even available at all until authentication completes
<halfline> so i think the fedora default is right, but i wonder why
it's not upstreamed
(...)
<halfline> yea the question is who should do it
<halfline> systemd or gdm
<halfline> or pam_env
(...)
! about username not being available until auth complete, this might
apply to fedora and not Debian.
Fedora uses pam_env at the auth PAM stage, and Debian which only run
pam_env for the session stage
(Debian does so except for /etc/pam.d/atd but that might be an "at"
Debian packaging bug)
--------------------
CVE-2010-4708
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4708 "
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.
"
--------------------
https://bugzilla.redhat.com/show_bug.cgi?id=641335
Bug 641335 (CVE-2010-3435) - CVE-2010-3435 pam: pam_env and pam_mail
accessing users' file with root privileges
Comment 3 Tomas Hoger 2010-10-08 20:23:15 UTC
Referenced discussion on these PAM issues also points out that
pam_env's intended behaviour of reading ~/.pam_environment is security
risk that may lead to environment changes unexpected to the system
administrator, service calling PAM, or subsequently consulted PAM
modules:
http://thread.gmane.org/gmane.comp.security.oss.general/3311/focus=3562
pam_env does not directly change programs environment and only does
changes to the environment associated with pam handle. Application can
later retrieve pam's environment via pam_getenvlist and export changes
to its environment. Other PAM modules can be affected if they use
pam_getenv.
Given the default use of pam_env for multiple, shall we consider
changing pam_env's user_readenv option default value to off?
~~~~~~~~~~~~~~~~~~~~
http://thread.gmane.org/gmane.comp.security.oss.general/3311/focus=3562
(not online anymore on HTTP, only NNTP)
NNTP thread (I cannot tell which email was target in this thread but I
supposed from the date of the comment in
https://bugzilla.redhat.com/show_bug.cgi?id=641335 that this was the
"Minor security flaw with pam_xauth" thread)
retrieved from NNTP, initial thread
https://seclists.org/oss-sec/2010/q3/183 and
https://www.openwall.com/lists/oss-security/2010/08/16/2
https://www.openwall.com/lists/oss-security/2010/10/01/11
https://seclists.org/oss-sec/2010/q4/10
Subjet: Re: Minor security flaw with pam_xauth
From: Vincent Danen <vdanen-h+wxahxf7alqt0dzr+a...@public.gmane.org>
Date: Fri, 1 Oct 2010 16:02:04 -0600
User-Agent: Mutt/1.5.20 (2009-12-10)
Reply to:
oss-security-zwoeplungu1jruoiu81ncdbpr1lh4...@public.gmane.org
* [2010-09-28 00:17:29 +0400] Solar Designer wrote:
>On Mon, Sep 27, 2010 at 11:36:13AM -0600, Vincent Danen wrote:
>> * [2010-09-24 20:48:23 +0400] Solar Designer wrote:
>> >pam_env and pam_mail accessing the target user's files as root (and
thus
>> >susceptible to attacks by the user) in Linux-PAM below 1.1.2,
partially
>> >fixed in 1.1.2 - no CVE ID mentioned yet
>> >
>> >pam_env and pam_mail in Linux-PAM 1.1.2 not switching fsgid (or
egid)
>> >and groups when accessing the target user's files (and thus
potentially
>> >susceptible to attacks by the user) - CVE-2010-3430
>> >
>> >pam_env and pam_mail in Linux-PAM 1.1.2 not checking whether the
>> >setfsuid() calls succeed (no known impact with current Linux
kernels,
>> >but poor practice in general) - CVE-2010-3431
>...
>> These that are partially fixed are fixed in that git commit you
noted
>> previously?
>>
>>
http://git.altlinux.org/people/ldv/packages/?p=pam.git;a=commitdiff;h=06f882f30092a39a1db867c9744b2ca8d60e4ad6
>>
>> Or are they fixed in different commits? It looks like they should
all
>> be fixed in that commit, but I want to double-check.
>
>No, they are not fully fixed at all. We're working on a patch (so you
>don't need to). The commit has the mentioned partial fixes only.
Oh, ok. Gotchya.
>> Are there patches available to fully fix these issues? And are
there
>> patches for 3430 and 3431 yet?
>
>This is the same question asked different ways. We have a patch that
>we're reviewing internally. To be made available soon.
Great, looking forward to seeing them.
>> I'm assuming also that those issues have
>> always existed although you say 'in 1.1.2', but they would affect
>> earlier versions yet, right?
>
>The original pam_env and pam_mail issues, yes. The partial fixes, no,
>because there were no fixes at all before 1.1.2.
Ok, that makes sense. I wasn't clear on the "partial fix" part.
>> Thanks for any clarification. I'm trying to wrap my head around
this
>> and the impact of these issues. They all strike me as relatively
minor
>> issues, but it is possible that I am missing or misunderstanding
>> something here.
>
>They're relatively minor because these modules are normally not used.
>However, if the modules are used in a PAM stack on a given install,
then
>the original issues reported against pam_env and pam_mail by Sebastian
>become major ones.
>
>Additionally, as mentioned by Sebastian, pam_env's intended behavior
is
>a security risk (user-provided env vars may affect some services in
ways
>not expected by the sysadmin). I am not sure how to deal with that.
>Maybe improve the documentation.
I'm not sure either, but I think that improving the documentation would
be a good start -- especially if that is pam_env's intended behaviour.
<missing from openwall.com archive>
Subjet: Re: Minor security flaw with pam_xauth
From: Solar Designer <solar-cxoSlKxDwOJWk0Htik3J/w...@public.gmane.org>
Date: Tue, 28 Sep 2010 00:17:29 +0400
User-Agent: Mutt/1.4.2.3i
Reply to:
oss-security-zwoeplungu1jruoiu81ncdbpr1lh4...@public.gmane.org
On Mon, Sep 27, 2010 at 11:36:13AM -0600, Vincent Danen wrote:
> * [2010-09-24 20:48:23 +0400] Solar Designer wrote:
> >pam_env and pam_mail accessing the target user's files as root (and
thus
> >susceptible to attacks by the user) in Linux-PAM below 1.1.2,
partially
> >fixed in 1.1.2 - no CVE ID mentioned yet
> >
> >pam_env and pam_mail in Linux-PAM 1.1.2 not switching fsgid (or
egid)
> >and groups when accessing the target user's files (and thus
potentially
> >susceptible to attacks by the user) - CVE-2010-3430
> >
> >pam_env and pam_mail in Linux-PAM 1.1.2 not checking whether the
> >setfsuid() calls succeed (no known impact with current Linux
kernels,
> >but poor practice in general) - CVE-2010-3431
...
> These that are partially fixed are fixed in that git commit you noted
> previously?
>
>
http://git.altlinux.org/people/ldv/packages/?p=pam.git;a=commitdiff;h=06f882f30092a39a1db867c9744b2ca8d60e4ad6
>
> Or are they fixed in different commits? It looks like they should
all
> be fixed in that commit, but I want to double-check.
No, they are not fully fixed at all. We're working on a patch (so you
don't need to). The commit has the mentioned partial fixes only.
> Are there patches available to fully fix these issues? And are there
> patches for 3430 and 3431 yet?
This is the same question asked different ways. We have a patch that
we're reviewing internally. To be made available soon.
> I'm assuming also that those issues have
> always existed although you say 'in 1.1.2', but they would affect
> earlier versions yet, right?
The original pam_env and pam_mail issues, yes. The partial fixes, no,
because there were no fixes at all before 1.1.2.
> Thanks for any clarification. I'm trying to wrap my head around this
> and the impact of these issues. They all strike me as relatively
minor
> issues, but it is possible that I am missing or misunderstanding
> something here.
They're relatively minor because these modules are normally not used.
However, if the modules are used in a PAM stack on a given install,
then
the original issues reported against pam_env and pam_mail by Sebastian
become major ones.
Additionally, as mentioned by Sebastian, pam_env's intended behavior is
a security risk (user-provided env vars may affect some services in
ways
not expected by the sysadmin). I am not sure how to deal with that.
Maybe improve the documentation.
Alexander
--------------------
https://exchange.xforce.ibmcloud.com/vulnerabilities/65037 "
Détails
linuxpam-pamenv-priv-escalation (65037) signalé 4 oct. 2010
Linux-PAM could allow a local attacker to gain elevated privileges on
the system, caused by an error in the pam_env module when reading the
.pam_environment file in a user's home directory. By executing a
program that relies on the pam_env PAM check, a local attacker could
exploit this vulnerability to run programs with an unintended
environment.
Conséquences :
Gain Access
Solution
Apply the appropriate patch for your system. See References.
"
https://web.archive.org/web/20210123213620/https://www.securityfocus.com/bid/46046/discuss
"
Linux-PAM 'pam_env' Module Local Privilege Escalation Vulnerability
Linux-PAM 'pam_env' module is prone to a local privilege-escalation
vulnerability.
Local attackers may possibly exploit this issue to change the expected
environment. This could lead to privilege escalation.
Linux-PAM 1.1.2 and prior versions are vulnerable.
" +
https://web.archive.org/web/20200229122701/https://www.securityfocus.com/bid/46046/solution
"
Linux-PAM 'pam_env' Module Local Privilege Escalation Vulnerability
Solution:
Updates are available. Please see the references for more information.
" +
https://web.archive.org/web/20200229122702/https://www.securityfocus.com/bid/46046/references
"
Linux-PAM 'pam_env' Module Local Privilege Escalation Vulnerability
References:
CVE-2010-4708 (Mitre)
Linux-PAM Home Page (Linux-PAM)
"
--------------------
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693995 "
From: Morita Sho <morita-pub-en-deb...@inz.sakura.ne.jp>
To: Debian Bug Tracking System <693...@bugs.debian.org>
Subject: Re: libpam-modules: ~/.pam_environment ignored
Date: Fri, 25 Jan 2013 14:30:03 +0900
(...)
the patch pam-1.1.3/debian/patches-applied/cve-2011-4708.patch changes
the default value of DEFAULT_USER_READ_ENVFILE to 0. It makes the
option user_readenv to be disabled by default and stops reading
~/.pam_environment.
It is inconsistent with the documentations and the manpage of pam_env
as they described ~/.pam_environment will be read by default.
It seems that cve-2011-4708.patch was made to fix CVE-2010-4708[1].
Note: The filename of the patch is incorrect. It should be
s/2011/2010/.
Upstream applied the same patch on 2010-10-11[2] so that set
DEFAULT_USER_READ_ENVFILE to 0, but the change has immediately been
reverted[3]. And DEFAULT_USER_READ_ENVFILE is still 1 in the latest
version[4].
[1] https://security-tracker.debian.org/tracker/CVE-2010-4708
[2]
http://git.fedorahosted.org/cgit/linux-pam.git/commit/modules/pam_env/pam_env.c?id=4c430f6f8391555bb1b7b78991afb20d35228efc
[3]
http://git.fedorahosted.org/cgit/linux-pam.git/commit/modules/pam_env/pam_env.c?id=f4aba7f47b87984fda3c5533b03b08a85e4ce81b
[4]
http://git.fedorahosted.org/cgit/linux-pam.git/tree/modules/pam_env/pam_env.c
Ubuntu seems to decided to keep DEFAULT_USER_READ_ENVFILE unchanged,
i.e. enabled by default[5].
[5]
http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-4708.html
I know the current behaviour can be changed so that pam_env will read
~/.pam_environment by modifying the files in /etc/pam.d/*. The
modification to let pam_env to read ~/.pam_environment can be made with
the following command:
# sed -i 's/pam_env.so.*/& user_readenv=1/' /etc/pam.d/*
But it would be useful and convenient if ~/.pam_environment is read by
default. FYI, Ubuntu recommended to use ~/.pam_environment to set per-
user environment variables[6].
[6]
https://help.ubuntu.com/community/EnvironmentVariables#Session-wide_environment_variables
(...)
From: Steve Langasek <vor...@debian.org>
To: Morita Sho <morita-pub-en-deb...@inz.sakura.ne.jp>,
693...@bugs.debian.org
Subject: Re: Bug#693995: libpam-modules: ~/.pam_environment ignored
Date: Thu, 24 Jan 2013 23:19:43 -0800
(...)
> Upstream applied the same patch on 2010-10-11[2] so that set
> DEFAULT_USER_READ_ENVFILE to 0, but the change has immediately been
> reverted[3]. And DEFAULT_USER_READ_ENVFILE is still 1 in the latest
> version[4].
> [1] https://security-tracker.debian.org/tracker/CVE-2010-4708
> [2]
http://git.fedorahosted.org/cgit/linux-pam.git/commit/modules/pam_env/pam_env.c?id=4c430f6f8391555bb1b7b78991afb20d35228efc
> [3]
http://git.fedorahosted.org/cgit/linux-pam.git/commit/modules/pam_env/pam_env.c?id=f4aba7f47b87984fda3c5533b03b08a85e4ce81b
> [4]
http://git.fedorahosted.org/cgit/linux-pam.git/tree/modules/pam_env/pam_env.c
Correct, but this is only because I've failed to follow through on it
upstream. There is a consensus now that this should default to 0.
> Ubuntu seems to decided to keep DEFAULT_USER_READ_ENVFILE unchanged,
i.e.
> enabled by default[5].
> [5]
http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-4708.html
Incorrect. The only decision was to not change the behavior in a
stable
release update. The next update of pam in Ubuntu will include this
change.
> I know the current behaviour can be changed so that pam_env will read
> ~/.pam_environment by modifying the files in /etc/pam.d/*. The
> modification to let pam_env to read ~/.pam_environment can be made
with
> the following command:
> # sed -i 's/pam_env.so.*/& user_readenv=1/' /etc/pam.d/*
> But it would be useful and convenient if ~/.pam_environment is read
by
> default. FYI, Ubuntu recommended to use ~/.pam_environment to set
> per-user environment variables[6].
And that's the reason that it was not changed in Ubuntu in a stable
update.
But it's still a security issue, which in the long term should be
addressed
by disabling userenv by default.
"
--------------------
linux-pam upstream user_readenv value history
https://github.com/linux-pam/linux-pam/commit/f83fb5f25263356391d71da595def409e8dd90f7
"
pam_env: Change the default to not read the user .pam_environment file
* modules/pam_env/pam_env.8.xml: Document the change.
* modules/pam_env/pam_env.c: Set DEFAULT_USER_READ_ENVFILE to 0.
v1.4.0
@t8m
t8m committed on 24 Feb 2020
"
<
https://github.com/linux-pam/linux-pam/commit/f4aba7f47b87984fda3c5533b03b08a85e4ce81b
"
revert preceding patch; under discussion, no consensus
master
v1.5.2 v1.5.1 v1.5.0 v1.4.0 v1.3.1 v1.1.6 v1.1.4 Linux-PAM-
1.3.0 Linux-PAM-1_2_1 Linux-PAM-1_2_0 Linux-PAM-1_1_8 Linux-PAM-1_1_7
Linux-PAM-1_1_5 Linux-PAM-1_1_4 Linux-PAM-1_1_3 Linux-PAM-1_1-branch
vorlonofportland committed on 11 Oct 2010
"
<
https://github.com/linux-pam/linux-pam/commit/4c430f6f8391555bb1b7b78991afb20d35228efc
"
Relevant BUGIDs:
Purpose of commit: bugfix
Commit summary:
2010-10-11 Tomas Mraz <t...@centrum.cz>
* modules/pam_env/pam_env.c: Change default for
user_readenv to 0.
* modules/pam_env/pam_env.8.xml: Document the new
default for user_readenv.
master
v1.5.2 v1.5.1 v1.5.0 v1.4.0 v1.3.1 v1.1.6 v1.1.4 Linux-PAM-
1.3.0 Linux-PAM-1_2_1 Linux-PAM-1_2_0 Linux-PAM-1_1_8 Linux-PAM-1_1_7
Linux-PAM-1_1_5 Linux-PAM-1_1_4 Linux-PAM-1_1_3 Linux-PAM-1_1-branch
"
On Tue, 31 Jan 2023 10:52:54 +0000 Colin Watson <cjwat...@debian.org> >
> Also, we need to track down an actual reason for this change.
> "Security concerns" is not verbose enough to be convincing on its
own.
> I found
>
https://github.com/linux-pam/linux-pam/commit/ecd526743a27157c5210b0ce9867c43a2fa27784
,
> which is not much better ("Due to problematic security ..."). My
best
> guess is that upstream got fed up after dealing with things like
> https://github.com/linux-pam/linux-pam/issues/263, but I'm really
just
> guessing, and proper documentation would actually explain this sort
of
> thing rather than just waving a security flag.
>
> I'm cloning this bug for the release notes, and CCing the PAM
maintainer
> for comments.
>
> Thanks,
>
> --
> Colin Watson (he/him)
[cjwat...@debian.org]
