Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Environment Variables Considered Harmful for Your Secrets

movingfast.io

Post reply on HN
Print view View original

81–90 of 120 posts

Re: Environment Variables Considered Harmful for Your Secrets

#81

Post by tibbon »

I created a quick gem (which you shouldn't install) that demonstrates having some untrusted code in your app which will post all of your environmental variables to a 3rd party server: https://github.com/tibbon/env_danger

Now, of course no one would install and run this... but I could imagine someone accidentally typing the name of a Gem wrong, someone accepting a bad PR (a sub-dependancy perhaps even doing so?), etc and somehow something untrusted getting in there. Yes, that means you have other problems, but it isn't outside the realm of possibility that accidental access like this is had.

Just because it shouldn't happen, doesn't mean it will never happen.

Re: Environment Variables Considered Harmful for Your Secrets

#82

Post by [deleted] »

jheriko wrote: post #38
bodyfour wrote: post #11

Classic UNIX behavior was that environment variables were public (any user could see them with the right flags to "ps") so it was well-known not to put anything secret there. Most (all?) of the current brand of UNIX variants have locked this down quite a while ago, which is a good thing. There are still a few old boxes kicking around though so if you're writing code that is meant to be widely deployed please don't pu…

This is the best argument for not doing this imo. "Classic UNIX behavior was that environment variables were public (any user could see them with the right flags to "ps") so it was well-known not to put anything secret there." The same logic applies to Windows environments and modern *nix too... Storing private data in a public location is obviously a bad idea.

[deleted]

Re: Environment Variables Considered Harmful for Your Secrets

#83

Post by klochner »

mreinsch wrote: post #18
CraigJPerry wrote: post #15

This article is misguided. Environment variables can be more secure than files. Furthermore, in the presented case there's no improvement in security by switching to a file. To address my second claim first: file permissions work at the user or group level. ACLs / MAC likewise. SELinux can be configured to assist in this case but it's not as trivial as it appears at first glance, it would be easier to use environment…

Thanks. I'm mainly looking at this from the point of how your secrets could be accidentally exposed. I applaud to postfix for sanitising the ENV, and it's very good practice to do so. But are all the frameworks doing it correctly? Maybe some code is then also just spawning new processes without sanitising? You could argue that's a bug then (which I completely agree), but not all projects are run like postfix...

I doubt many projects take the same disciplined (akin to micro-services) approach that postfix does:

     ... mail delivery is done by daemon processes that have no parental 
    relationship with user processes. This eliminates a large variety of 
    potential security exploits with environment variables, signal handlers, 
    and with other process attributes that UNIX passes on from parent to child.

 [edit] sorry for the spam, there was some problem with the submission form.

Re: Environment Variables Considered Harmful for Your Secrets

#85

Post by jstultz »

fartclops wrote: post #84

While I could simply tell you to blank out ENV vars once you've internalized them, I will instead write an infinitely long essay on how they are "considered harmful" that contributes absolutely nothing back to society.

This is not always an option; the argument applies as well to using tools written by others that expect secrets to be provided in an environment variable. The AWS SDK is a popular example. While it will also happily read credentials from a configuration file, or allow them to be explicitly passed, it's a popular method and is the only one that is consistent across the various SDKs that AWS provides.

Re: Environment Variables Considered Harmful for Your Secrets

#86

Post by jstultz »

moe wrote: post #61

1. It's easy to grab the whole environment and print it out (can be useful for debugging) or send it as part of an error report for instance. If you have software in your deployment that will send "error reports" to untrusted third parties then you have bigger problems than your shell environment. 2. The whole environment is passed down to child processes If you don't trust your child processes then you have bigger p…

Is it so inconceivable that one might trust error reports to third parties, but not secret keys?

Re: Environment Variables Considered Harmful for Your Secrets

#87

Post by phunge »

There's a not-widely-publicized feature of Linux that allows programs to store secrets directly in the kernel: https://www.kernel.org/doc/Documentation/security/keys.txt That has some advantages, including the guarantee that it can't be swapped to disk. Kerberos can use it for secret storage, I haven't seen it used elsewhere though.

It looks like process-private storage is one of its features.

Re: Environment Variables Considered Harmful for Your Secrets

#88

Post by perlgeek »

jmillikin wrote: post #36
perlgeek wrote: post #33

Earlier quoted context omitted.

The system sounds very well thought-out, though probably not applicable at my $work location. > When an app on another server is started up, it must be done from a shell That's a no-go for many setups. It doesn't integrate well with how Linux distros usually start services (systemd, upstart, sysv init, ...), and means you have to have another way to manage dependencies between your services. > When an app on another…

> That's a no-go for many setups. It doesn't integrate well > with how Linux distros usually start services (systemd, > upstart, sysv init, ...) Change the daemon config file to use a small wrapper script, which initializes the SSH environment and then execs the target binary. Assuming a reasonable setup, this should be trivial. > At this point you could have used ssh right away, no? > Any reason you used TLS + check…

> Change the daemon config file to use a small wrapper script, which initializes the SSH environment and then execs the target binary. Assuming a reasonable setup, this should be trivial.

Well, the point is that the ssh needs to have forwarded agent from somewhere else. If the host on which the service is run can initiate it, the whole security aspect is gone.

> This would have fewer potential security issues than trying to lock down a user's SSH login shell.

Locking down a login shell (usually be not running a shell in the first place) is a solved problem, and for example gitolite uses it has the base of its architecture. Yes, you have to be careful, but you must also be careful when manually validating certificates.

Re: Environment Variables Considered Harmful for Your Secrets

#89

Post by moe »

jstultz wrote: post #86
moe wrote: post #61

1. It's easy to grab the whole environment and print it out (can be useful for debugging) or send it as part of an error report for instance. If you have software in your deployment that will send "error reports" to untrusted third parties then you have bigger problems than your shell environment. 2. The whole environment is passed down to child processes If you don't trust your child processes then you have bigger p…

Is it so inconceivable that one might trust error reports to third parties, but not secret keys?

Either you exercise control over what you send, or you don't.

This has nothing to do with your choice of configuration method.

Re: Environment Variables Considered Harmful for Your Secrets

#90

Post by ntucker »

perlgeek wrote: post #33
ntucker wrote: post #22

My company has an internal bit of infrastructure that I think is a somewhat novel approach that allows us to never have any secrets stored unencrypted on disk. There's a server (a set of servers, actually, for redundancy) called the secret server, and its only job is to run a daemon that owns all the secrets. When an app on another server is started up, it must be done from a shell (we use cap) which has an SSH agent…

The system sounds very well thought-out, though probably not applicable at my $work location. > When an app on another server is started up, it must be done from a shell That's a no-go for many setups. It doesn't integrate well with how Linux distros usually start services (systemd, upstart, sysv init, ...), and means you have to have another way to manage dependencies between your services. > When an app on another…

> At this point you could have used ssh right away, no? Any reason you used TLS + checking SSH agent instead?

Yeah, using the SSH login method is actually quite slow for something you want to call at app startup on N instances during a push (at a minimum, your process responsible for whatever gatekeeping you do has to be respawned for every request, which necessarily puts a lower bound on the latency). I'm sure this could have been tracked down and optimized, but as jmillikin points out, another downside is that the additional per-user config can get kind of messy and error prone. Implementing logic like this at the .ssh/config level is (in my opinion) kind of easy to goof up and hard to test.

Post reply on HN