Environment Variables are insecure and transferred to new repository owners

[AWegnerGitHub]

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

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 is still an important issue - is there any timeline to getting this resolved, or at least acknowledged?

[redbeard]

@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]

That is correct

…

On Mon, Jun 25, 2018, 11:51 PM Tal Rotbart ***@***.***> wrote: @AWegnerGitHub <https://github.com/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? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9430 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGKb54GgRVtBdWq9EuRv_vYNrX3ZvjB9ks5uAb2_gaJpZM4TD1y3> .

[Undo1]

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.

[stale]

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]

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

[AWegnerGitHub]

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

[pathurs]

This security issue is easily exploited by "Social Hacking" (AKA "Social Engineering").

Party A is the owner of the GitHub Repository and, therefore, the Travis CI Project owner.
Party B is the "Social Hacker".

Party A has been working on an Open Source project for a fair while, has a very robust automated build process with Travis CI, including secure tokens to GitHub, and a few other third-party deploy targets. These tokens are kept secure using the Environment Variables settings in Travis CI.

Party B starts to contribute to this Open Source GitHub Repository, and over a few weeks to months, gains a small amount of trust from Party A. Party A decides to add Party B to their GitHub Repository "team", with write access.

Party A starts to get busy with other projects, and considers abandoning the Open Source GitHub Repository, however, Party B volunteers to maintain it instead. Party A agrees.

Party A transfers ownership of the GitHub repository to Party B.

Party B can now manipulate the .travis.yml file to print all Environment Variables by, for example, reversing the order of the string value of each Environment Variable.

Party B has now stolen secure tokens from Party A.

[angussidney]

Would it be possible to get an update on the status of your fix for this security vulnerability?

[earonesty]

The trivial fix is to wipe secure vars then the owner changes hands. Seems the safe thing to do. It's like when you send a broken phone in for repairs ... you gotta back up your data and wipe the phone. Even if it's annoying... it's probably the best bet.

That's why they moved the factory data reset option into the main settings menu. Same thing for Travis.

As a nice to have... if someone really want to transfer secure env vars at the same time... add a checkbox or something that an owner can flip that's good for one insecure move.... and then gets flipped back.

[stale]

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

[ArtOfCode-]

Bad bot. This is still a security issue. Confirmed security issues should not be closed, ever, until they're fixed.

[stale]

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

[ArtOfCode-]

See above... again. @BanzaiMan @redbeard.

[stale]

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

[ArtOfCode-]

Bad bot. Bad. Go sit in the corner.