
Travis CI Security Advisory: Secured Environment Variables - edmorley
https://blog.travis-ci.com/2017-05-08-security-advisory
======
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?

~~~
jacques_chester
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/](https://buildpacks.ci.cf-app.com/)

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

------
0x0
When I submitted a pull request to a random open source project, I was
surprised to see a travis build kick off immediately.

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.

~~~
roidrage
That wouldn't be possible, and that's independent of the security issue we've
disclosed in the post.

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-...](https://docs.travis-ci.com/user/pull-
requests#Pull-Requests-and-Security-Restrictions)

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

~~~
nothrabannosir
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.

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

~~~
nothrabannosir
Right, but now you're in the "review of a PR didn't catch malicious code"
boat. At which point, you've got bigger problems than leaking env vars in your
CI.

Not to dismiss it---it's just a different point.

------
arekkas
Did they bother to notify the repositories affected by this? Could not find
anything.

~~~
mattcoles
> We have been in close communications with GitHub since we began working on
> this incident, and have shared impacted tokens with GitHub for their
> records. GitHub will revoke token access for the affected tokens and will
> contact token owners to notify them. Both Travis CI and GitHub recommend
> affected owners revoke their own access tokens and create new tokens
> immediately.

Seems like both Github and Travis did.

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

~~~
phalangion
What is a better pattern?

~~~
jacques_chester
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.

~~~
dogecoinbase
_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.

~~~
jacques_chester
That's definitely one way of looking at it.

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.

------
andrewvc
While I love travis for what it is, this is a foreseeable result here.

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.

~~~
tehlike
What if the token was encrypted or altered in a way simple find replace
wouldnt work?

~~~
ReverseCold
Even just encoding it differently (base64, bin, hex, etc) would work against
that.

