Description

Historically, private repositories have used SSH deploy keys with write access. This meant that in the case of pull-requests from private forks of private repositories or pull-requests to recently open-sourced private repositories, the SSH keys could be accessed. This vulnerability was responsibly reported by Cash Williams and Dane Powell from Acquia to security@travis-ci.com. We have already updated our integration to create read-only ssh deploy keys and believe it is unlikely this vulnerability has been exploited.

More Background

In order to clone private repositories on travis-ci.com, we add a deploy key when Travis is enabled for the repository.

When we first implemented support for private GitHub repositories in 2011, it was only possible to acquire a SSH deploy key that had write access. This has changed in the meantime, GitHub rolled out support for read-only deploy keys, however until recently our integration had not been updated to make use of that change.

Unfortunately, this allowed for a form of privilege escalation in one particular scenario: users with the ability to create pull requests to a private repository from a private fork were able to gain access to the deploy keys. Those deploy keys would then allow the user to gain write access. That only affects private repositories.

The second case in which these keys could have been exposed is for private repositories that were made public. Due to a separate bug, we would continue running those builds on travis-ci.com (we usually run public builds on travis-ci.org). This would allow public pull requests to gain access to the key for a short period of time after the repository was made public.

Addressing the Vulnerability

As a first step, we ensured that newly enabled repositories create a read-only key. Next, we worked with GitHub to update all existing deploy keys to be read-only. The keys themselves have not been changed, only the read-only flag has.

We also made sure that public repositories are always detected as public on travis-ci.com, and that builds for repositories that were made public no longer run on that platform.

Finally, pushing changes from within a build is also no longer possible. The presence of a read/write key during builds is something that many users rely on, in order to push changes back to the repository as part of a build. With the transition to read-only keys, that is no longer possible.

Recommendations

If you are affected by this limitation, you can create an extra deployment key for your repository in GitHub’s repository settings, and instruct us to use that alternative key, by following these instructions:

• Generate the key pair with openssl or openssh. If you run ssh-keygen -f deploy_rw -N '', you should get two files: deploy_rw.pub and deploy_rw.
• Navigate to the repository settings on GitHub, and add a deploy key. Here you can paste the public key. If you used ssh-keygen, that is the contents of deploy_rw.pub.
• Go to your repository settings on https://travis-ci.com, and add the private key of your custom key pair there. If you used ssh-keygen, that is the contents of deploy_rw.

See our documentation for more details.

Acknowledgments

Our thanks go out to Cash Williams and Dane Powell from Acquia, for responsibly disclosing this vulnerability to security@travis-ci.com and for their input as we researched and addressed the situation.

GitHub security also has gone above and beyond in their support and understanding in mitigating this issue. Thank you! 💕

If you have any questions, please contact support@travis-ci.com.