Travis CI quietly fixed a bug that exposed secret keys

For at least a week, cloning a public repo made upstream environmental variables accessible

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. ®

Broader topics

Other stories you might like

  • DigitalOcean tries to take sting out of price hike with $4 VM
    Cloud biz says it is reacting to customer mix largely shifting from lone devs to SMEs

    DigitalOcean attempted to lessen the sting of higher prices this week by announcing a cut-rate instance aimed at developers and hobbyists.

    The $4-a-month droplet — what the infrastructure-as-a-service outfit calls its virtual machines — pairs a single virtual CPU with 512 MB of memory, 10 GB of SSD storage, and 500 GB a month in network bandwidth.

    The launch comes as DigitalOcean plans a sweeping price hike across much of its product portfolio, effective July 1. On the low-end, most instances will see pricing increase between $1 and $16 a month, but on the high-end, some products will see increases of as much as $120 in the case of DigitalOceans’ top-tier storage-optimized virtual machines.

    Continue reading
  • GPL legal battle: Vizio told by judge it will have to answer breach-of-contract claims
    Fine-print crucially deemed contractual agreement as well as copyright license in smartTV source-code case

    The Software Freedom Conservancy (SFC) has won a significant legal victory in its ongoing effort to force Vizio to publish the source code of its SmartCast TV software, which is said to contain GPLv2 and LGPLv2.1 copyleft-licensed components.

    SFC sued Vizio, claiming it was in breach of contract by failing to obey the terms of the GPLv2 and LGPLv2.1 licenses that require source code to be made public when certain conditions are met, and sought declaratory relief on behalf of Vizio TV owners. SFC wanted its breach-of-contract arguments to be heard by the Orange County Superior Court in California, though Vizio kicked the matter up to the district court level in central California where it hoped to avoid the contract issue and defend its corner using just federal copyright law.

    On Friday, Federal District Judge Josephine Staton sided with SFC and granted its motion to send its lawsuit back to superior court. To do so, Judge Staton had to decide whether or not the federal Copyright Act preempted the SFC's breach-of-contract allegations; in the end, she decided it didn't.

    Continue reading
  • US brings first-of-its-kind criminal charges of Bitcoin-based sanctions-busting
    Citizen allegedly moved $10m-plus in BTC into banned nation

    US prosecutors have accused an American citizen of illegally funneling more than $10 million in Bitcoin into an economically sanctioned country.

    It's said the resulting criminal charges of sanctions busting through the use of cryptocurrency are the first of their kind to be brought in the US.

    Under the United States' International Emergency Economic Powers Act (IEEA), it is illegal for a citizen or institution within the US to transfer funds, directly or indirectly, to a sanctioned country, such as Iran, Cuba, North Korea, or Russia. If there is evidence the IEEA was willfully violated, a criminal case should follow. If an individual or financial exchange was unwittingly involved in evading sanctions, they may be subject to civil action. 

    Continue reading

Biting the hand that feeds IT © 1998–2022