Travis CI Security Advisory: Secured Environment Variables
blog.travis-ci.com
blog.travis-ci.com
Run it through sed?
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
Is there a chance for rogue pull requests to contain (build) code that dumps out travis environment secrets? I didn't explore this but obviously the code is being built by scripts that are part of the commit.
For pull requests Travis CI has long had security measures in place to prevent this scenario from happening: https://docs.travis-ci.com/user/pull-requests#Pull-Requests-...
Not to dismiss it---it's just a different point.
Seems like both Github and Travis did.
But storing secrets in environment variables isn't a universally bad thing (which is what I interpret "anti-pattern" to mean). It's a bad thing in certain contexts, including OSes (e.g., AIX and OpenBSD) where environment variables are readable by any local user. But there are certainly uses of it where it's more secure than any alternative (e.g., mosh uses $MOSH_KEY for this and it's pretty sound), and except for the OSes where environment variables are intentionally world-readable, most attacks that would let you read an environment variable would also let you read any other place to store a secret, including a file, a pipe, or a special kernel thing like Linux keyrings.
It's very common to print them out while debugging, but not common to print arbitrary files containing your credentials. I have yet to see phpinfo() print ~/.ssh/id_rsa to the world for example, but I sure have pulled a lot of passwords out of it.
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.
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
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.
Another view is that:
1. You can't invest in heavily defending scattered resources.
2. Individual teams are not all experts in secret management.
Pivotal started CredHub (it's now in the Cloud Foundry Incubation process) partly because of client requests and partly because of the problems we and our fellow Cloud Foundry Foundation members have encountered. There are literally thousands of secrets and credentials scattered across dozens of teams, including hundreds of high-risk operational secrets.
We have had multiple unintentional leakages, usually git. It's so easy that we now have tools to watch commits and checkouts for secret-like patterns. The same tools constantly comb our repositories for possible secrets as well.
Development teams should not need to care. Operators should not need to have to hand-manage thousands of secrets. There should be a safe, sane, central, highly assured place or places to keep your secrets.
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 variables seems like a reasonable compromise to me.
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 severity finding that was barely worth logging, and a full remote compromise.
[1] https://github.com/spc476/CGILib/blob/master/src/crashreport...
At the very least they need to add a failsafe that checks all outgoing logs for any secure tokens and replaces them with '*' or something.
If you sign up to play a game of whack-a-mole you will lose eventually.