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

Travis CI Security Advisory: Secured Environment Variables

blog.travis-ci.com

Post reply on HN
Print view View original

21–30 of 38 posts

Re: Travis CI Security Advisory: Secured Environment Variables

#21

Post by eropple »

lawnchair_larry wrote: post #18
karlmdavis wrote: post #5

Earlier quoted context omitted.

I'd love to know, too. Best as I can tell, the only really secure option is to read them in from STDIN. Depending on how the process is running, it may also be reasonably secure to read the secrets from files. But getting this right is tricky, and really prone to human error: all it takes is one errant chmod/chown to remove the security. Honestly, given the challenges of those options, keeping secrets in environment…

Even putting them in text files is far better than environment variables. Consider how often people log environment variables or even leave phpinfo() lying around. As someone who does penetration tests, I can tell you that it's far more common to gain access to environment variables than it is to read files on the server. The difference between services that didn't have secrets there and the ones that did was a low s…

How often people log environment variables? Maybe the places I've worked are outliers, but `puts ENV.inspect` or the use of PHP wouldn't pass code review in my prior gigs, nor would they be things I'd write today. My experience is literally the opposite--somebody forgetting a chmod is a lot more common than somebody leaking environment variables like that (leaving it up to somebody to figure out a really smart way to read `/proc/pid/environ` or something).

Re: Travis CI Security Advisory: Secured Environment Variables

#22

Post by mintplant »

> As this fix runs in Ruby, it results in larger memory overhead. To address this, we are working on an executable binary that will be installed as part of the build-image. Work on this is expected to be complete by the end of the week.

Run it through sed?

Re: Travis CI Security Advisory: Secured Environment Variables

#23

Post by jacques_chester »

mintplant wrote: post #22

> As this fix runs in Ruby, it results in larger memory overhead. To address this, we are working on an executable binary that will be installed as part of the build-image. Work on this is expected to be complete by the end of the week. Run it through sed?

We hit this in Cloud Foundry Buildpacks, where all the builds and logs are completely public[0].

The team wrote and added Concourse-Filter[1]. You stream logs through it. It compares what's going past to current environment variables. Anytime something goes past that looks like one of the environment variables, it blanks it out.

You can set a whitelist for things you're not fussed about.

Disclosure: I have twice worked on Buildpacks on behalf of Pivotal.

[0] https://buildpacks.ci.cf-app.com/

[1] https://github.com/pivotal-cf-experimental/concourse-filter

Re: Travis CI Security Advisory: Secured Environment Variables

#24

Post by jacques_chester »

phalangion wrote: post #3
lawnchair_larry wrote: post #2

Secrets in environment variables is such a bad security anti-pattern, and it seems to be getting more popular.

What is a better pattern?

Secrets or credential management is hard, but the first step is to centralise. Many folk use Vault. There's also Knox, KeyWhiz and I forget some others. I've been a secrets-management product team (CredHub) for several months now.

We've looked at different ways of shuttling secrets but really, it's going to be specific to the context. For example, one job our software does is to hand credentials to a trusted BOSH director during deployments. That's basically done at this point and works very nicely from an operator perspective.

But then when we look at handing secrets to applications, or getting secrets to CI, it's a bit trickier.

We use Concourse a lot and for Concourse the next major track of work centres entirely around creating a secrets-management layer that backs onto secret-management systems.

Disclosure: At the moment I work on CredHub on behalf of Pivotal.

Re: Travis CI Security Advisory: Secured Environment Variables

#25

Post by lgas »

eropple wrote: post #21
lawnchair_larry wrote: post #18

Earlier quoted context omitted.

Even putting them in text files is far better than environment variables. Consider how often people log environment variables or even leave phpinfo() lying around. As someone who does penetration tests, I can tell you that it's far more common to gain access to environment variables than it is to read files on the server. The difference between services that didn't have secrets there and the ones that did was a low s…

How often people log environment variables? Maybe the places I've worked are outliers, but `puts ENV.inspect` or the use of PHP wouldn't pass code review in my prior gigs, nor would they be things I'd write today. My experience is literally the opposite--somebody forgetting a chmod is a lot more common than somebody leaking environment variables like that (leaving it up to somebody to figure out a really smart way to…

I suspect the vast majority of software development organizations do not do code reviews, so you're already in the minority.

Re: Travis CI Security Advisory: Secured Environment Variables

#26

Post by tehlike »

nothrabannosir wrote: post #16
tehlike wrote: post #12

Earlier quoted context omitted.

Doesnt this still make it potentially available in case some malicious/unmalicious coder leaves some console debugging out?

Only if you merge it in. The point is the secure environment variables are not available at all in the fork build. The bash oneliner they show is to help you run scripts which won't crash if they don't have those env vars available, not to "hide them" by running a test script which doesn't use them.

I know many instances where code reviews didnt catch log statement in huge binaries.

Re: Travis CI Security Advisory: Secured Environment Variables

#27

Post by eropple »

lgas wrote: post #25
eropple wrote: post #21

Earlier quoted context omitted.

How often people log environment variables? Maybe the places I've worked are outliers, but `puts ENV.inspect` or the use of PHP wouldn't pass code review in my prior gigs, nor would they be things I'd write today. My experience is literally the opposite--somebody forgetting a chmod is a lot more common than somebody leaking environment variables like that (leaving it up to somebody to figure out a really smart way to…

I suspect the vast majority of software development organizations do not do code reviews, so you're already in the minority.

Distressingly likely. Point taken.

Re: Travis CI Security Advisory: Secured Environment Variables

#28

Post by eropple »

jacques_chester wrote: post #24
phalangion wrote: post #3

Earlier quoted context omitted.

What is a better pattern?

Secrets or credential management is hard, but the first step is to centralise. Many folk use Vault. There's also Knox, KeyWhiz and I forget some others. I've been a secrets-management product team (CredHub) for several months now. We've looked at different ways of shuttling secrets but really, it's going to be specific to the context. For example, one job our software does is to hand credentials to a trusted BOSH dir…

Not applicable for y'all, but for our AWS people, I'll cape up for Credstash[1] (or its moral equivalent, Sneaker[2], but I prefer the use of a Dynamo table to S3 for this). Uses IAM to ensure secret access and offers revisioning. Plus it's super easy to work with. My normal stack, using my own Auster[3] for orchestration, uses an offline, file-based secrets store (usually an encrypted USB key in production) for stuff like database root passwords that don't need to be online, then push database passwords into Credstash with encryption contexts (the KMS thing that makes IAM effective for this). My Chef cookbooks happily slurp in credstashed secrets via rcredstash, now that the PR to make it work with parameterized KMS keys has hit, and provisioning is very straightforward. (There are a lot of proper nouns in this paragraph, but the nice thing is that each component handles its own business and so there aren't many vertical concerns.)

CI secret access isn't a thing in the systems I develop (unit tests don't need them, integration tests get a spun-up environment that provisions its own secrets), but you could provide access with a bog-standard token machine.

[1] https://github.com/fugue/credstash

[2] https://github.com/codahale/sneaker

[3] https://github.com/eropple/auster

Re: Travis CI Security Advisory: Secured Environment Variables

#29

Post by spc476 »

eropple wrote: post #21
lawnchair_larry wrote: post #18

Earlier quoted context omitted.

Even putting them in text files is far better than environment variables. Consider how often people log environment variables or even leave phpinfo() lying around. As someone who does penetration tests, I can tell you that it's far more common to gain access to environment variables than it is to read files on the server. The difference between services that didn't have secrets there and the ones that did was a low s…

How often people log environment variables? Maybe the places I've worked are outliers, but `puts ENV.inspect` or the use of PHP wouldn't pass code review in my prior gigs, nor would they be things I'd write today. My experience is literally the opposite--somebody forgetting a chmod is a lot more common than somebody leaking environment variables like that (leaving it up to somebody to figure out a really smart way to…

I've written code that does that [1] to log information to help diagnose crashes in long running daemons. Now, the dumping of environment variables is optional but it has been helpful to me in isolating issues with some CGI based programs (as Apache passes critical information to the script in environment variables). Of course, it was in a situation where core dumps are not generated so anything related to a crash is helpful.

[1] https://github.com/spc476/CGILib/blob/master/src/crashreport...

Re: Travis CI Security Advisory: Secured Environment Variables

#30

Post by dogecoinbase »

jacques_chester wrote: post #24
phalangion wrote: post #3

Earlier quoted context omitted.

What is a better pattern?

Secrets or credential management is hard, but the first step is to centralise. Many folk use Vault. There's also Knox, KeyWhiz and I forget some others. I've been a secrets-management product team (CredHub) for several months now. We've looked at different ways of shuttling secrets but really, it's going to be specific to the context. For example, one job our software does is to hand credentials to a trusted BOSH dir…

Secrets or credential management is hard, but the first step is to centralise.

Ah yes, the "all eggs, one basket" approach to secret management. This is the correct approach, if you are trying to sell a platform -- gets you lock-in, and if you fail to keep secrets secure, you were going to blow up anyways, so the business risk management dictates that you should shoot for the moon and risk your client's data in the hopes of getting traction.

Post reply on HN