4 ms·

Could you elaborate? How are environment variables insecure? If the secret will be present in the application throughout it's lifetime, then what's a better alt

Could you elaborate? How are environment variables insecure? If the secret will be present in the application throughout it's lifetime, then what's a better alternative? Just because a secret is injected into the application as an environment variable does not mean it's handled insecurely elsewhere. For example, AWS ECS containers have built-in support for fetching secrets from Secret Manager at startup and passing them as environment variables: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/secrets-envvar.html https://docs.aws.amazon.com/AmazonECS/latest/developerguide/... This fetches the secret at the time the container starts up (IIRC), and uses the IAM credentials of the running application to fetch them from Secret Manager (so it must have permission to the secret). The merit of using environment variables seems to depend entirely on how they are, well, configured. With a mechanism like this I don't see much disadvantage. (The main disadvantage I see is that generic malware that attempts to dump environment variables might capture them, but defending against that threat is largely obfuscation, unless you aren't storing the secret at all permanently in memory.)

dathinab 3y ago
- any sub process has full unlimited access to env variables - env variables are prone to be dumped in various contexts and might leak secrets to e.g. logs - env variables might leak, e.g. in context of docker build stages etc. (but then using building a docker image to build both the image and the software is often anyway not a good idea) - env variables are often easily accessible by other processes the method you mentioned of ad-hoc injecting a secret as env by some form of security manager for containers avoid many such problems
- lazyant 3y ago
  > - env variables are often easily accessible by other processes A process would need to have the same permission (same user) or root to read /proc/$PID/environ no? or what mechanism is there for a process to read another process env vars (not children processes, that was already mentioned)? unless of course, a process dumped them in some world-readable file (like logs as mentioned) or some other silly way
  - ezekg 3y ago
    Exactly. The operating system already offers security for environment variables: use it. And you get the benefit of increased security in other places by not sharing users between applications.
    - dathinab 3y ago
      except no it does not, env variables wherent designed to be secure and the degree of secruity the system provides is like a bad joke if you take security serious still works if your system is a single application container otherwise it does not
      - ezekg 3y ago
        I'm not sure I agree. If that were true, the security of the user system itself would also be a bad joke and it's not. Regardless, what I meant is that the OP made it sound like they're using the same server and user and container for multiple applications, but if they did things correctly, the risk of sharing environment variables across applications wouldn't exist.
        dathinab 3y ago
        The problem is the env stays readily accessible to most programs with similar permissions and all child programs if no special actions are taken. This is (part of) the reason programs accept secrets like passwords normally only (or strongly recommended) over stdin or similar instead of env variable or cmdline. Or why it's not rare (or was in the past, probably is today) to have a encrypted cert file and inject the password to it through a side channel. It's also not rare for programs to dump environment variables in various situations, including to logs. Or e.g. an intrusion detection program might snapshot all programs running + their cmd arguments + their (creation) env and then run analysis on it. And while you can use e.g. selinux and similar to add a ton of security and prevent such issues, or use systemd to run the program under ad-hoc users with minimal permissions and various isolation it's very often not done. EDIT: To be clear I'm not saying you can't use secrets in environment variables safely. I'm saying by default by their design environment variables are not "secure for secret passing". But many things for which stuff like that is true can, under the right circumstances, still be used securely.
- yjftsjthsd-h 3y ago
  > env variables might leak, e.g. in context of docker build stages etc. (but then using building a docker image to build both the image and the software is often anyway not a good idea) Since the rule describes runtime configuration, it shouldn't be involved with the build process at all
sergioisidoro 3y ago
My comment is specific to docker, although environment as a broader sense can be discussed. I remember reading that it is possible to end up in situations where your environments can end up in the layers of the docker image. Also, you can read the secrets of a container with inspect, and apparently linked containers might be able to access other containers's secrets. I think it was this article: https://snyk.io/blog/keeping-docker-secrets-secure/ https://snyk.io/blog/keeping-docker-secrets-secure/
derefr 3y ago
Presumably because /proc/$PID/environ exists and can be read by the user that owns the process — which means that any attacker that can figure out how to spawn an arbitrary subprocess running as the daemon user (a pretty common vulnerability class!) can exfiltrate all your env-vars. It's similar to the reason that you're not supposed to supply passwords on the command-line (/proc/$PID/cmdline exists), but instead either read them from stdin, or do the big dance of 1. creating a file that contains the password, is owned by root, and is 0400; 2. having your daemon start off running as root for just long enough to read the password into process memory; 3. then having your daemon drop privileges before doing any work, so that someone exploiting the daemon won't have the privilege as the "do the work" user to read the file with the password in it.

dathinab 3y ago

- any sub process has full unlimited access to env variables - env variables are prone to be dumped in various contexts and might leak secrets to e.g. logs - env variables might leak, e.g. in context of docker build stages etc. (but then using building a docker image to build both the image and the software is often anyway not a good idea) - env variables are often easily accessible by other processes the method you mentioned of ad-hoc injecting a secret as env by some form of security manager for containers avoid many such problems

lazyant 3y ago
> - env variables are often easily accessible by other processes A process would need to have the same permission (same user) or root to read /proc/$PID/environ no? or what mechanism is there for a process to read another process env vars (not children processes, that was already mentioned)? unless of course, a process dumped them in some world-readable file (like logs as mentioned) or some other silly way
- ezekg 3y ago
  Exactly. The operating system already offers security for environment variables: use it. And you get the benefit of increased security in other places by not sharing users between applications.
  - dathinab 3y ago
    except no it does not, env variables wherent designed to be secure and the degree of secruity the system provides is like a bad joke if you take security serious still works if your system is a single application container otherwise it does not
    - ezekg 3y ago
      I'm not sure I agree. If that were true, the security of the user system itself would also be a bad joke and it's not. Regardless, what I meant is that the OP made it sound like they're using the same server and user and container for multiple applications, but if they did things correctly, the risk of sharing environment variables across applications wouldn't exist.
      - dathinab 3y ago
        The problem is the env stays readily accessible to most programs with similar permissions and all child programs if no special actions are taken. This is (part of) the reason programs accept secrets like passwords normally only (or strongly recommended) over stdin or similar instead of env variable or cmdline. Or why it's not rare (or was in the past, probably is today) to have a encrypted cert file and inject the password to it through a side channel. It's also not rare for programs to dump environment variables in various situations, including to logs. Or e.g. an intrusion detection program might snapshot all programs running + their cmd arguments + their (creation) env and then run analysis on it. And while you can use e.g. selinux and similar to add a ton of security and prevent such issues, or use systemd to run the program under ad-hoc users with minimal permissions and various isolation it's very often not done. EDIT: To be clear I'm not saying you can't use secrets in environment variables safely. I'm saying by default by their design environment variables are not "secure for secret passing". But many things for which stuff like that is true can, under the right circumstances, still be used securely.
yjftsjthsd-h 3y ago
> env variables might leak, e.g. in context of docker build stages etc. (but then using building a docker image to build both the image and the software is often anyway not a good idea) Since the rule describes runtime configuration, it shouldn't be involved with the build process at all

sergioisidoro 3y ago

My comment is specific to docker, although environment as a broader sense can be discussed. I remember reading that it is possible to end up in situations where your environments can end up in the layers of the docker image. Also, you can read the secrets of a container with inspect, and apparently linked containers might be able to access other containers's secrets. I think it was this article: https://snyk.io/blog/keeping-docker-secrets-secure/ https://snyk.io/blog/keeping-docker-secrets-secure/

derefr 3y ago

Presumably because /proc/$PID/environ exists and can be read by the user that owns the process — which means that any attacker that can figure out how to spawn an arbitrary subprocess running as the daemon user (a pretty common vulnerability class!) can exfiltrate all your env-vars. It's similar to the reason that you're not supposed to supply passwords on the command-line (/proc/$PID/cmdline exists), but instead either read them from stdin, or do the big dance of 1. creating a file that contains the password, is owned by root, and is 0400; 2. having your daemon start off running as root for just long enough to read the password into process memory; 3. then having your daemon drop privileges before doing any work, so that someone exploiting the daemon won't have the privilege as the "do the work" user to read the file with the password in it.