Travis CI Flaw Exposed Secrets of Thousands of Open Source Projects

An anonymous reader quotes a report from Ars Technica: Travis CI is a popular software-testing tool 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 builds. Environment variables can include sensitive secrets like signing keys, access credentials, and API tokens. If these variables are exposed, attackers can abuse the secrets to obtain lateral movement into the networks of thousands of organizations.

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. Another place encrypted secrets may be defined is Travis' web UI. 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, Travis is expected to run in a manner that prevents public access to any secret environment variables specified. [...] 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.

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, Peter Szilagyi details the arduous process that his group endured as it waited for Travis CI to take action and release a 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 Szilagyi. After Szilagyi and Lange asked GitHub to ban Travis CI over its 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 Szilagyi, while referring to the security bulletin -- and especially its abridged version, which included barely any details. Szilagyi 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.'" "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."

Open Source Secrets

[zenlessyank]

That almost sounds like an oxymoron.

Re:

[Narcocide]

Well, it sure is on GitHub, anyway. I am Jack's complete lack of surprise.

Re: Open Source Secrets

[klipclop]

Heads should roll for this one

Travis not GitHub

[AleRunner]

This is Travis, not GitHub. They released a blog entry [travis-ci.com] which doesn't even link to their own bulletin. Starting to move off Travis at this point would make sense. This is not trustworthy behaviour. Moving from GitHub to GitLab would also make sense but that's not related to this problem - instead it's because GitLab has an Open Source edition and so you can self host and/or fix later if you wish.

Re:

[Ostracus]

"Information wants to be free."

Re:

[AleRunner]

That almost sounds like an oxymoron.

Only if two conditions are met:
1. One does not understand open source.
2. One is a moron.

an oxy - moron?

Re:

[Anonymous Coward]

It's also consistent with Richard M. Stallman's attitudes about security. He was infamous at MIT for setting his password to blank, or when compelled to have a password to set his account "rms" to the password "rms", and to leave computer science systems he might have access to for open access because of just such attitudes. It's what got him kicked out of the computer labs at Kendall Square, part of MIT's facilities where he'd been a brilliant, but very eccentric, guest for years.

rms is.... not a moron, bu

Re:

[echo123]

Richard Stallman won't use a web browser [lwn.net], instead his "demon" [sic] emails web content to himself.

Re:

[Anonymous Coward]

refusing to admit that rules have some uses and leaving devastation in his wake.

"rules" that aren't applied to everyone equally are injustice. Most people supporting BLM or even supporting "defund the police" are not against rules, they're against a corrupt institution that has ignore the rules for far too long. All we ask if that if you drag a woman out of her car to beat her senselessly, that you don't use her child as a prop on social media [yahoo.com]

Example of Cognative Dissonance

[theshowmecanuck]

So many who talk about the cloud not really being secure because cloud really just means 'somebody else's computer'. And then you have to trust them not to fuck it up and/or leave security holes. Then they use Github... on somebody else's computer. And then automated tools to write/commit your code, build it, test it, that need to be secure, especially if you are building proprietary shit... running on somebody else's computer. I know it works OK most of the time, but risk is two parts, yeah. Likelihood and consequences. I guess if the risk is acceptable, fill yer boots. Deploying a final product on Amazon or some other infrastructure is definitely not as worrisome to me than storing the intellectual property that made it in the cloud. Single point of failure with a high enough potential value to make it a target, as opposed to hacker groups having to hit tens of thousands of IP addresses individually.

Two things

[phantomfive]

1) Don't check secrets into source control, even if they are encrypted. The encryption you used might already be broken, and you don't follow the right crypto forums to be notified when it does get broken.

2) Don't make your CI tools accessible on the public internet. Put it behind a VPN because they all have security bugs.

Re:

[stephanruby]

"So don't use encryption, use an encrypted network." That's your advice?!

Re:

[phantomfive]

There are two reasons:

1) "only use one encryption system" instead of one for your secrets, one for your internet traffic, etc. It's simpler, there's less room for human error.

2) The VPN prevents unauthenticated traffic from even touching your CI server, and breaking through that is a more difficult attack than merely reading an encrypted message.

Not a fan of CI/CD

[bradley13]

CI/CD tools make deployment easy. Too easy. It's too easy to deploy crap, because it's too easy to just push a button. People were (are) handing this 3rd party tool the keys to their kingdoms. Which have now been compromised. Because they wanted that so-easy, one-click deployment process. Small violins...

Works as designed

[gillbates]

If this had happened because a programmer had made a mistake, it would be that programmer's responsibility. But, because they're using Travis CI, the blame is deflected to someone else.

The fact of the matter is that security holes are almost impossible to avoid on any project of non-trivial complexity. The reason why third-party systems like this are used is because it allows blame to be shifted to someone else in the event of a security breach. And it's working - yes, the vendor looks bad, but a secur

Too much diversity :]

[terrorubic]

Diversity [travis-ci.com]: “*Being different makes us a healthier team and a better company. As a diverse and inclusive team our perspectives and backgrounds enable us to make better decisions.*”

Wow, talk about brazen BS

[Aighearach]

"Travis CI implemented a series of security patches starting on Sept 3rd that resolves this issue"

They're actually trying to credit the introduction of the bug as part of the solution to the bug, to screw up the dates and make it look like a same-day response.

Lame and sleazy.

I'm glad I went with a more professional CI system for my own code. Travis CI was the very first one I evaluated, because I prefer Ruby for high-level code. But it just didn't have the features I wanted.

Testing Tool

[Simonowen]

It was obvious. A testing tool that clones your code can never be a safe choice for an open-source project. Although they are resolving the issue through a series of security patches, what has been done is done now. The secrets that have been exposed cannot be reverted back. But kudos to the Travis CI team, they are at least doing efforts to compensate for the loss.

Re:

[Remiluke]

Yes, you are right. Thanks to the researcher Felix Lange who found a security vulnerability. Travis CI was considered an efficient testing tool and still people relying on it. and now when they have included secure environment variables of all public open-source repositories, the tool has gained more trust of people in my honest opinion.

Re:

[Isaackane]

Well, I don’t think so. Look it’s a cloud-based tool and many of us think that the cloud is not really secure. The reason is that you are using somebody’s computer for data storage. 2ndly Travis CI compels people to trust as they claimed they will not leave security holes. But on the other hand, they use Github to test and deploy the code. Mean your data is going into the hands of a third party on somebody else's computer again. Maybe it works well most of the time, but are we really sure

Re:

[Remiluke]

I agree with you up to some extent. I am not saying that their system was flawless. If they are using automated tools to clone your source code to test it, the environment should be highly encrypted. Someone is providing you their property and you should maintain its secrecy. But it's a technology world and no one is perfect. They tried their best to provide the best services to clients for testing codes by using popular tools. If there is an issue with security protocol happens, they are also liable to res

Re:

[Remiluke]

Travis CI has always stated that there is no availability of Encrypted environment variables from forks to pull requests due to the security risk involved. If the risk of exposing such information to unknown code is there, then why do developers trust Travis CI? It's due to its efficiency and the no record of such a significant security breach. The timely research of Felix Lange has saved Travis from being unreliable.

Re:

[Isaackane]

Researchers who identified the bug notified the company of it on September 7. Travis CI has requested all the clients to rotate their secrets as a precaution despite implementing security patches. It means Travis is really serious when it comes to keeping secrets from their clients. But they have realized that the system is somewhat flawed. Now let's see what they have in their kitty for future endeavors.

Re:

[Simonowen]

Indeed they are doing a great job in implementing security protocols and removing the bug. However, that’s not enough. I am sure they will come up with a more efficient policy regarding security encryption to avoid any data and secret theft in the future.

Re:

[Isaackane]

Look what is written in the document, despite all the measures, Travis CI has infuriated the developer community. Travis CI has faced a backlash for various reasons. There is no analysis, no report on security, not a single warning to developers for any type regarding the exposure of secrets the developers may face. And that leads to people demanding the ban of Travis CI from GitHub. That is a big question mark on the Travis CI management for handling the issue poorly.

Re:

[Simonowen]

As I said earlier the damage has been done so no one can do anything to recover the loss. However, they are taking a major step in implementing a security patch and they will get back with a bang for sure. Have faith and give them some time. Let's see what is in the future they going to offer.