The Travis CI flaw has revealed the secrets and techniques of 1000’s of open supply initiatives

A security flaw in Travis CI has the potential to expose the secrets of thousands of open source projects that rely on hosted continuous integration. Travis CI is a software testing solution used by 900,000 open source projects and 600,000 users. A vulnerability in the tool makes it possible for secure environment variables—registration keys, access credentials, and API tokens of all public open source projects—to be manipulated.

Worse, the dev community was upset about the poor handling of the vulnerability disclosure process and the short “security bulletin” that had to be forced out of Travis.

Environmental variables are injected into the pump query parameters

Travis CI is a popular software testing tool because of 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 new dedicated virtual environment and performs various tasks to build and test your code. If one or more of those tasks fail, the writing is considered broken. If none of the tasks fail, the build is considered passed and Travis CI can send your code to the web server or application host.

But this month, researcher Felix Lange found a security vulnerability that caused Travis CI to include protected environment variables every public open source repositories that use Travis CI in pull request builds. Environment variables can include sensitive secrets such as signing keys, login credentials, and API tokens. If these variables are exposed, attackers can use the secrets to get external traffic into networks of thousands of parties.

A simple GitHub search reveals that Travis is widely used by a large number of projects:

Tracked as CVE-2021-41077, the bug is in the deployment process of Travis CI and affects some builds created between September 3 and September 10. As part of this activation process, developers are supposed to add the “.travis.yml” file to their open source project repository. This file tells Travis CI what to do and what it can contain is encrypted. Another place where encryption can be found is Travis website UI. But, these secrets are not meant to be revealed. In fact, the Travis CI documentation has always said, “Encrypted environment variables are not available to fork requests due to the security risk of exposing such information to unknown code.”

Ideally, Travis is expected to work in a way that prevents public access to any specified private environment variables.

“Secure environment variables … are configured on Travis’ UI and are only owned by Travis,” Péter Szilágyi, Ethereum cryptocurrency project lead told Ars. “These variables are then added to the environment of the working buildings, but for dependent code (i.e. merged code). For external code (PRs), you should not insert env vars, since the maintainer does not in control. on the code left by the outsiders. The problem is that they mess something up and end up giving the secret keys to the most untrusted foundations.”

This vulnerability makes these types of secrets accidentally exposed to just about anyone who hacks public storage and publishes files during a write process.

Fortunately, the matter did not last too long – around eight days, thanks to Lange and other researchers who informed the company of the bug on September 7. But for the sake of caution, all tasks that rely on Travis CI is advised to change their secrets.

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

“According to the received report, a public repository sold from another can file a pull request (regular activity, for example, in GitHub, BitBucket, Assembla) and in the process get unauthorized access to secrets from the original public repository includes the mode of publishing some files during the build process,” explained Montana Mendy of Travis CI in a security bulletin. “In this scenario, the secrets are still stored in the Travis CI database.”

Mendy said the issue applies to public repositories and not to private repositories, because the owners of the latter have full control over who can fork their repositories.

The public was outraged by the weak “security press”.

The presence and rapidity of the flaw aside, Travis CI’s concise security bulletin and overall control of the integrated disclosure process have angered the development community.

In a lengthy Twitter thread, Péter Szilágyi explained the painstaking process his team endured while waiting for Travis CI to take action and released a short security bulletin on the exposed website.

“After 3 days of pressure from several projects, (Travis CI) silently patched the issue on the 10th. No analysis, no security report, no post death, did not warn any of their users that their secrets may have woken up,” tweeted Szilágyi.

After Szilágyi and Lange asked GitHub to ban Travis CI due to the poor security situation and weak disclosure guidelines, the opinion shows. “Finally, after many ultimatums from many projects, (they) posted this lame-ass post hidden deep where no one will read it… Not even a single ‘thank you.’ (No) acknowledges responsible disclosure. It doesn’t even charge all of it,” Szilágyi said, while pointing to the security bulletin—and even his abridged versionwhich includes any details.

Many locals joined Szilágyi in criticizing the newspaper. Boston-based web developer Jake Jarvis called the show’s “disgraceful ‘security bulletin’ is insane.”

But Travis CI thinks rolling secrets is something developers should do anyway. “Travis CI implemented a series of security patches starting on September 3 that resolve this issue,” Mendy concluded on behalf of the Travis CI team. “As a reminder, cycling your secrets is something that all users should do it regularly. If you don’t know how to do this, please contact Support.”

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

Update: 20:59 PT – added answer from Szilágyi received after press time and the secrets he explained were not revealed from the “travis.yml” file, as indicated by the CVE advicebut rather Travis’ internet interface.