Travis CI flaw exposed secrets of thousands of open source projects

A security flaw in Travis CI potentially exposed secrets of thousands of open source projects that rely on the hosted continuous integration service. Travis CI is a software-testing solution used by over 900,000 open source projects and 600,000 users. However, a vulnerability in the tool made it possible for secure environment variables—signing keys, access credentials, and API tokens of all public open source projects—to be exfiltrated.

Worse, the dev community is upset about the poor handling of the vulnerability disclosure process and a thinly worded “security bulletin” it had to force out of Travis.

Environment variables injected into PR builds

Travis CI is a popular choice of software-testing tool among developers due to its seamless integration with GitHub and Bitbucket. As the makers of the tool explain:

When you run a build, Travis CI clones your GitHub repository into a brand-new virtual environment and carries out a series of tasks to build and test your code. If one or more of those tasks fail, the build is considered broken. If none of the tasks fail, the build is considered passed and Travis CI can deploy your code to a web server or application host.

But this month, researcher Felix Lange found a security vulnerability that caused Travis CI to include secure environment variables of all public open source repositories that use Travis CI into pull request (PR) builds. Environment variables can include sensitive secrets like signing keys, access credentials, and API tokens. If these things are exposed, attackers can abuse the secrets to obtain lateral movement into networks of thousands of organizations.

A simple GitHub search demonstrates that Travis is in widespread use by a large number of projects:

Tracked as CVE-2021-41077, the bug is present in Travis CI’s activation process and impacts certain builds created between September 3 and September 10. As a part of this activation process, developers are supposed to add a “.travis.yml” file to their open source project repository. This file tells Travis CI what to do and may contain encrypted secrets. But these secrets are not meant to be exposed. In fact, Travis CI’s docs have always stated, “Encrypted environment variables are not available to pull requests from forks due to the security risk of exposing such information to unknown code.”

Ideally, for a customer-provided “travis.yml” file present in a Git repository, Travis is expected to run in a manner that prevents public access to any secret environment variables specified in the YML file. Put simply, when a public project is forked (copied), the “.travis.yml” file, along with these secrets, is included in the fork. That’s not supposed to happen. But this vulnerability caused these sorts of secrets to be unexpectedly exposed to just about anyone forking a public repository and printing files during a build process.

Fortunately, the issue didn’t last too long—around eight days, thanks to Lange and other researchers who notified the company of the bug on September 7. But out of caution, all projects relying on Travis CI are advised to rotate their secrets.

While not exactly similar in nature, the vulnerability has echoes of the Codecov supply chain attack in which threat actors had exfiltrated secrets and sensitive environment variables of many Codecov customers from their CI/CD environments, leading to further data leaks at prominent companies.

“According to a received report, a public repository forked from another one could file a pull request (standard functionality, e.g., in GitHub, BitBucket, Assembla) and while doing it obtain unauthorized access to secrets from the original public repository with a condition of printing some of the flies during the build process,” explained Montana Mendy of Travis CI in a security bulletin. “In this scenario, secrets are still encrypted in the Travis CI database.”

Mendy says the issue only applies to public repositories and not private repositories, as repository owners of the latter have full control over who can fork their repositories.

Community furious over flimsy “security bulletin”

The presence and relatively quick patching of the flaw aside, Travis CI’s concise security bulletin and overall handling of the coordinated disclosure process has infuriated the developer community.

In a long Twitter thread, Ethereum cryptocurrency project lead Péter Szilágyi details the arduous process that his company endured as it waited for Travis CI to take action and release an brief security bulletin on an obscure webpage:

“After 3 days of pressure from multiple projects, [Travis CI] silently patched the issue on the 10th. No analysis, no security report, no post mortem, not warning any of their users that their secrets might have been stolen,” tweeted Szilágyi.

After Szilágyi and Lange asked GitHub to ban Travis CI over poor security posture and vulnerability disclosure processes, an advisory showed up. “Finally, after multiple ultimatums from multiple projects, [they] posted this lame-ass post hidden deep where nobody will read it… Not even a single ‘thank you.’ [No] acknowledgment of responsible disclosure. Not even admitting the gravity of it all,” said Szilágyi, while referring to the security bulletin—and especially its abridged version, which had barely any details.

Szilágyi was joined by several members of the community in criticizing the bulletin. Boston-based web developer Jake Jarvis called the disclosure an “insanely embarrassing ‘security bulletin.'”

But Travis CI thinks rotating your secrets is something you should be doing anyway. “Travis CI implemented a series of security patches starting on Sept 3rd that resolves this issue,” concluded Mendy on behalf of the Travis CI team. “As a reminder, cycling your secrets is something that all users should do on a regular basis. If you are unsure how to do this, please contact Support.”

Ars has reached out to both Travis CI and Szilágyi for further comment, and we are awaiting their responses.