Another case of environment variables causing LPE. Wonder if we'll ever end up with something more robust for passing details between processes than parsing ambient settings from strings.
Instead of using something standard like environment variables, pam has a special "pam_env" that contains facts about the user session that it apparently trusts. Users can override pam_env settings by writing to hidden file in ~.
So, this exploit chain is more accurately described as "yet another example of utilities inventing new, obscure configuration mechanisms for security-critical settings, allowing policy flaws to remain undetected for a long time".
Running security configuration options through a special snowflake IPC mechanism (instead of keeping them in a file where they could actually be inspected by humans) would only make things worse.
If they mutated the real environment it could be even worse, since they're still privileged code and there are all sorts of environment variables that libraries read at runtime using `secure_getenv`.
I finally understand why they're trying to deprecate `pam_env`, despite its incredible utility. For some reason, instead of only applying its contents to the user environment for the child process like any sane person would do, they are trusting its values for the library calls in the privileged parent itself.
> For some reason, instead of only applying its contents to the user environment for the child process like any sane person would do, they are trusting its values for the library calls in the privileged parent itself.
The only safe way to use pam_env's `user_readenv` parameter is as the final rule of `type=session`. This behaves as you'd expect, affecting the child process only.
It appears that openSUSE enables the option for other rule types (auth and/or account), in which case it affects the parent process as well. Oops!
For the record, user_readenv has been disabled since:
commit 4c430f6f8391555bb1b7b78991afb20d35228efc
Author: Tomas Mraz <[email protected]>
Date: Mon Oct 11 14:24:30 2010 +0000
Relevant BUGIDs:
Purpose of commit: bugfix
Commit summary:
---------------
2010-10-11 Tomas Mraz <[email protected]>
* 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.
... PAM 1.1.3. And it's been deprecated for a while, to be removed in a future release entirely.
At the time they hadn't and I'm fed up of the jumping to conclusions that env vars are the cause of any security issue. This is blaming poor code from poor devs on expert features from UNIX all to often.
Worrying when said person has authored a widely used security product(!). This is a bad trend in the industry that needs to stop.
I'm talking about this comment. Are you talking about this comment? From what knowledge I have, it looks like a good explanation of the problem and why it's not an environment variable problem.
I'll say it again - environment variables or pam_env aren't expert features - they're primitive. They were a contributing factor in the first privilege escalation.
