Travis CI quietly fixed a bug that exposed secret keys
From at least September 3 through September 10, public open-source code repositories that used Travis CI exposed their sensitive keys, credentials, and tokens to potential theft.
Travis CI – the CI being continuous integration – allows developers to automate processes for testing and building software. Developers using a CI system often deal with passwords, access tokens, and API keys that should not be exposed in public source code repositories and are thus typically stored separately as environmental variables.
Due to a flaw in the way Travis CI handled environmental variables, a public repository forked from another repo could file a pull request that would collect the secret environmental variables set in the original upstream repository.
And that’s a serious security problem, particularly for such widely used software. As of 2019, Travis CI was used in more than 932,977 open-source projects and by more than 600,000 users [PDF]. A GitHub search for the travis.yml configuration file returns more than 35m results.
After Ethereum developer Felix Lange identified the secret leakage on September 7, and the issue was reported to Travis CI, the Berlin-based firm fixed the flaw on September 10.
According to Ethereum team lead Péter Szilágyi, Travis CI had to be pushed to address the vulnerability and then failed to adequately explain the situation to customers.
“After 3 days of pressure from multiple projects, @travisci silently patched the issue on the 10th,” he said via Twitter. “No analysis, no security report, no post mortem, not warning any of their users that their secrets might have been stolen.”
Finally on Monday, Travis CI posted a security bulletin in its forum and elsewhere on its website advising developers that “cycling your secrets is something that all users should do on a regular basis.”
The vulnerability is tracked as CVE-2021-41077, but that’s not mentioned in the advisory.
Travis CI’s documentation cites the risk of secret exposure during the build process and describes how sensitive data should be encrypted before being stored in the .travis.yml configuration file.
“A pull request sent from a fork of the upstream repository (we call it an ‘external pull request’) could be manipulated to expose environment variables,” the company’s docs state. “The upstream repository’s maintainer would have no protection against this attack, as pull requests can be sent by anyone who forks the repository on GitHub.”
Travis CI says it accounts for this by making encrypted variables and data available only to internal pull requests – those from the same repo. “Pull requests sent from forked repositories do not have access to encrypted variables or data even if these are defined in the fork source project,” the company’s documentation says.
And in its advisory, Travis CI downplays the severity of the situation by noting that if a pull request from a forked repo is created, “secrets are still encrypted in the Travis CI database.”
Szilágyi, however, told The Register in an email that the secrets were still accessible as a result of this vulnerability.
“The secrets are encrypted while on disk at Travis, but when the build starts, they are decrypted (by Travis) and injected into the builds in the form of [environmental variables],” he explained. “Accessing them is simply reading the contents.”
As an example, he pointed to one of his repo attacks, which writes secrets out in base64 encoding via the command
echo $SECRET | base64. “The first part prints the secret and the second tumbles it a bit so Travis doesn’t censor it out from the logs,” he said.
Aghast at the way Travis CI handled the situation, Szilágyi advised developers to consider an alternative CI provider.
For those looking to see if they have any visible secrets of this sort, David Brownman, senior platform engineer at Zapier, has devised a Python script to scan public repos for exposed environmental keys.
Travis CI did not respond to a request for comment. ®
via The Register https://ift.tt/3gv0n1Y
September 15, 2021 at 03:04PM