Hacker Neue

Preferences
mkj parent
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
IPC ?
hedora
The GP doesn't understand the vulnerability:

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.

o11c
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.

mkj OP
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.

yrro
> 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
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
Relax, someone else already explained it without shouting.
rob_c
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
> At the time they hadn't

Their comment was before yours.

rob_c
if that's the comment you mean, it also misses the point
Dylan16807
https://www.hackerneue.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.

This item has no comments currently.