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

11–20 of 38 posts

Re: Travis CI Security Advisory: Secured Environment Variables

#11

Post by roidrage »

0x0 wrote: post #10

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.

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

Re: Travis CI Security Advisory: Secured Environment Variables

#12

Post by tehlike »

roidrage wrote: post #11
0x0 wrote: post #10

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.

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

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

Re: Travis CI Security Advisory: Secured Environment Variables

#13

Post by tehlike »

andrewvc wrote: post #4

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.

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

Re: Travis CI Security Advisory: Secured Environment Variables

#14

Post by tehlike »

kyrra wrote: post #8
phalangion wrote: post #3

Earlier quoted context omitted.

What is a better pattern?

Encrypt the data at rest with an encryption appliance (HSM). Or use a key management service[0][1] to store encryption keys that can be used to decrypt your at-rest data. [0] https://cloud.google.com/kms/ [1] https://aws.amazon.com/kms/

+1 with kms you could implement access control for different jobs.

Re: Travis CI Security Advisory: Secured Environment Variables

#15

Post by tomjakubowski »

lawnchair_larry wrote: post #2

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

Storing secrets elsewhere wouldn't have prevented this specific problem, where git potentially leaked credentials (in URL form) to the build log.

Re: Travis CI Security Advisory: Secured Environment Variables

#16

Post by nothrabannosir »

tehlike wrote: post #12
roidrage wrote: post #11

Earlier quoted context omitted.

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

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.

Re: Travis CI Security Advisory: Secured Environment Variables

#17

Post by geofft »

lawnchair_larry wrote: post #2

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

Storing secrets elsewhere (for some value of elsewhere that may or may not be better than environment variables) would not have helped this vulnerability: even if the OAuth token were in a file, and it were copied into .git/config, git would still have printed the URL on a failed push.

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.

Re: Travis CI Security Advisory: Secured Environment Variables

#18

Post by lawnchair_larry »

karlmdavis wrote: post #5
phalangion wrote: post #3

Earlier quoted context omitted.

What is a better pattern?

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 severity finding that was barely worth logging, and a full remote compromise.

Re: Travis CI Security Advisory: Secured Environment Variables

#19

Post by lawnchair_larry »

geofft wrote: post #17
lawnchair_larry wrote: post #2

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

Storing secrets elsewhere (for some value of elsewhere that may or may not be better than environment variables) would not have helped this vulnerability: even if the OAuth token were in a file, and it were copied into .git/config, git would still have printed the URL on a failed push. But storing secrets in environment variables isn't a universally bad thing (which is what I interpret "anti-pattern" to mean). It's a…

I think you have some faulty assumptions. Environment variables are not usually disclosed because somebody got shell access.

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.

Post reply on HN