Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Environment Variables are insecure and transferred to new repository owners #9430

Open
AWegnerGitHub opened this issue Apr 2, 2018 · 8 comments

Comments

Projects
None yet
5 participants
@AWegnerGitHub
Copy link

commented Apr 2, 2018

If a GitHub repository is transferred to a new owner, all associated environment variables are transferred as well - including the "secure" ones.

Reproduction - Short Version

The short version is this:

  1. On one GitHub account, create a repository with a .travis.yml file
  2. On the Travis CI account associated with step 1, set up an environment variable and elect not to show the value in the build log
  3. Transfer the GitHub repository to another account.

At this point, the environment variables defined in step 2 are accessible by the new owner from step 3.


The longer version is that these "secure" variables aren't actually secure. Simple string manipulations can expose the variables in the build log and they are transferred to the new owner.

I've written a longer write up on this bug here. It was originally reported in December of 2017 to the security team, but multiple followups haven't been responded to. At this point, we're over three months since the initial report and I feel others need to know that their environment variables can be accessed if you transfer your repository or if you have a malicious commit applied to your build scripts, where you manipulate the build log string outputs to show the variable values.

@ArtOfCode-

This comment has been minimized.

Copy link

commented Apr 23, 2018

Is this likely to get a response from the Travis team at some point? It's a fairly niche vulnerability, to be entirely fair, but it's also a fairly serious security hole for those who are impacted but don't know it.

@Undo1

This comment has been minimized.

Copy link

commented Jun 21, 2018

This is still an important issue - is there any timeline to getting this resolved, or at least acknowledged?

@redbeard

This comment has been minimized.

Copy link

commented Jun 26, 2018

@AWegnerGitHub -- could you validate my understanding that for this to be exploited it would require an attacker to transfer ownership of the original github repo with which the Travis CI build was configured?

@AWegnerGitHub

This comment has been minimized.

Copy link
Author

commented Jun 26, 2018

@Undo1

This comment has been minimized.

Copy link

commented Jun 26, 2018

The threat model here isn't really an attacker (if an attacker gets into your GitHub account, it's all over anyway). The issue is that secrets can be inadvertently transferred with no indication or warning in the UI, and no way for the original owner to realize his secrets have been compromised until it's too late.

@BanzaiMan BanzaiMan added the security label Sep 18, 2018

@stale

This comment has been minimized.

Copy link

commented Dec 17, 2018

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue in 7 days. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please respond before the issue is closed, or open a new one after. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

@stale stale bot added the stale label Dec 17, 2018

@BanzaiMan BanzaiMan removed the stale label Dec 17, 2018

@stale

This comment has been minimized.

Copy link

commented Mar 17, 2019

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue in 7 days. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please respond before the issue is closed, or open a thread on the community forum. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

@stale stale bot added the stale label Mar 17, 2019

@AWegnerGitHub

This comment has been minimized.

Copy link
Author

commented Mar 17, 2019

This is still labeled a security issue. I don't believe it should be closed before being fixed.

@stale stale bot removed the stale label Mar 17, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.