5 ms·

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 amb

by mkj 1y ago

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.

hansmayer 1y ago
IPC ?
- hedora 1y ago
  The GP doesn't understand the vulnerability: https://cdn2.qualys.com/2025/06/17/suse15-pam-udisks-lpe.txt https://cdn2.qualys.com/2025/06/17/suse15-pam-udisks-lpe.txt 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.
  - mkj 1y ago
    Ok yeah, I had actually misread what the vars were. But it's the same kind of problem as general environment vars - rather than just a name, maybe it needs metadata of where it came from. To be clear, I'm talking about the unprivileged to allow_active CVE-2025-6018, not the allow_active to root.
  - Piraty 1y ago
    https://xeiaso.net/talks/surreal-horror-pam-2021-11-09/ https://xeiaso.net/talks/surreal-horror-pam-2021-11-09/
  - o11c 1y ago
    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.
  - yrro 1y ago
    > 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 <tm@t8m.info> Date: Mon Oct 11 14:24:30 2010 +0000 Relevant BUGIDs: Purpose of commit: bugfix Commit summary: --------------- 2010-10-11 Tomas Mraz <t8m@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. ... PAM 1.1.3. And it's been deprecated for a while, to be removed in a future release entirely.
rob_c 1y ago
NO, this is NOT environment variables. It's the wrong argument to a tool, but the suid part has nothing to do with environment variables or cleaning the env up. PLEASE STOP SPREADING FUD.
- Dylan16807 1y ago
  Relax, someone else already explained it without shouting.
  - rob_c 1y ago
    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.
    - Dylan16807 1y ago
      > At the time they hadn't Their comment was before yours.
      - rob_c 1y ago
        if that's the comment you mean, it also misses the point
        Dylan16807 1y ago
        https://news.ycombinator.com/item?id=44355306 https://news.ycombinator.com/item?id=44355306 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.
    - mkj 1y ago
      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.

by mkj 1y ago

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.

hansmayer 1y ago

IPC ?

hedora 1y ago
The GP doesn't understand the vulnerability: https://cdn2.qualys.com/2025/06/17/suse15-pam-udisks-lpe.txt https://cdn2.qualys.com/2025/06/17/suse15-pam-udisks-lpe.txt 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.
- mkj 1y ago
  Ok yeah, I had actually misread what the vars were. But it's the same kind of problem as general environment vars - rather than just a name, maybe it needs metadata of where it came from. To be clear, I'm talking about the unprivileged to allow_active CVE-2025-6018, not the allow_active to root.
- Piraty 1y ago
  https://xeiaso.net/talks/surreal-horror-pam-2021-11-09/ https://xeiaso.net/talks/surreal-horror-pam-2021-11-09/
- o11c 1y ago
  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.
- yrro 1y ago
  > 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 <tm@t8m.info> Date: Mon Oct 11 14:24:30 2010 +0000 Relevant BUGIDs: Purpose of commit: bugfix Commit summary: --------------- 2010-10-11 Tomas Mraz <t8m@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. ... PAM 1.1.3. And it's been deprecated for a while, to be removed in a future release entirely.

rob_c 1y ago

NO, this is NOT environment variables. It's the wrong argument to a tool, but the suid part has nothing to do with environment variables or cleaning the env up. PLEASE STOP SPREADING FUD.

Dylan16807 1y ago
Relax, someone else already explained it without shouting.
- rob_c 1y ago
  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.
  - Dylan16807 1y ago
    > At the time they hadn't Their comment was before yours.
    - rob_c 1y ago
      if that's the comment you mean, it also misses the point
      - Dylan16807 1y ago
        https://news.ycombinator.com/item?id=44355306 https://news.ycombinator.com/item?id=44355306 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.
  - mkj 1y ago
    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.