7 ms·
Use GitHub actions at your own risk
- rgoldfinger 7y agoThe same could be said for any use of docker images. Seems a little unfair to single out Github.
- reilly3000 7y agoThat's definitely true, but given the sensitivity of having access to private source and secrets I think its fair to call out a warning.
- ericlewis 7y agocouldn't a malicious docker image also be tooled to dump all of that stuff to an external destination?
- reilly3000 7y agoAbsolutely. CI systems tend to get broad access to everything sacred. Giving that level of access to community code is risky in the least.
- ZitchDog 7y agoTotally agreed. However, when do we stop making this mistake? I think it's worth a callout when a large organization designs a dependency management system with such an obvious flaw on the "happy path".
- mleonhard 7y agoIt should be possible to import specific docker imager versions into a private repository and use them for production. With Gitlab.com: https://docs.gitlab.com/ee/user/packages/container_registry/ https://docs.gitlab.com/ee/user/packages/container_registry/ https://docs.gitlab.com/ee/ci/docker/README.html https://docs.gitlab.com/ee/ci/docker/README.html
- rattray 7y agoTitle should be adjusted to mention branches & tags specifically.
- polymeris 7y ago> Each hash is supposed to be unique and you cannot rewrite history with the exact same SHA-1. I thought SHA-1 wasn't considered secure?
- tilt_error 7y agoIt isn’t, according to NIST.
- SahAssar 7y agoSee https://marc.info/?l=git&m=148787047422954 https://marc.info/?l=git&m=148787047422954 for some of linus thoughts about this.
- btouellette 7y agoThere are collision attacks against it but GitHub should be detecting and protecting against those. See https://github.blog/2017-03-20-sha-1-collision-detection-on-github-com/ https://github.blog/2017-03-20-sha-1-collision-detection-on-...
- robbya 7y agoIt's insecure for certain applications. Here is Linus on SHA-1 in git: https://www.theregister.co.uk/2017/02/26/git_fscked_by_sha1_collision_not_so_fast_says_linus_torvalds/ https://www.theregister.co.uk/2017/02/26/git_fscked_by_sha1_...
- cordite 7y agoA known collision brings a hash algorithm to be "not secure" for cryptographic use. It doesn't mean there is a reliable way to come up with an equivalent hash for different data. That said, hashes like md5 are still plenty used in ETags for http 304s all the time despite being considered insecure for cryptographic use.
- MattPalmer1086 7y agoIt's not secure for many applications. There are various practical collision attacks on it. However, to rewrite history you need a preimage attack. In other words, you need to find a value X which hashes to the same hash value y which already exists h(X)=y These are not currently practical. So SHA1 is certainly not recommended, but isn't completely broken yet.
- safaci2000 7y agoThis also applies to most library, docker (as mentioned) and basically anything you use that's 3rd party. I suppose it varies on your level of paranoia, though honestly if you rely on a github action in your production flow you should fork the project. Never mind doing something malicious, they could just as easily delete the entire repo and now your critical feature you needed to deliver are blocked because the library you were relying one has disappeared. Anything you use in a critical path you should control. If you're managing your own fork, nobody will inject bad code except yourself. Just my 2 cents. Also, the things that github 3rd party actions are doing is usually not that complicated. I mean how many different ways can you publish a docker image or deploy an artifact to S3. Once it works, it either works or doesn't. It's not a programming library where optimizations are created or we fixed a security vulnerability (though I suppose that can come up ). Sorry minor rant. food for thought.
- awintr 7y agocame here to say this.
- xeromal 7y agoDo you fork your own programming languages too?
- jen20 7y agoNot so much a fork as a package cache - but usually for anything important, absolutely.
- npo9 7y agoWe definitely standardize runtime and compiler versions across runtime environments and build servers and have planned upgrade paths with rollback options.
- amdelamar 7y agoShould fork the OS its running on too! /s
- robbya 7y agoThis is correct, using a commit hash is safer. However, you'll sometimes want to update the commit hash after the action's maintainer releases new code. If you don't then you run the risk of running an old action that has vulnerable components or bugs. The easiest workflow for that should be Dependabot's updater for GitHub actions: https://dependabot.com/github-actions/ https://dependabot.com/github-actions/ Has anyone tried that approach for GitHub actions? You still need to review the action's code before you use it, and every time you update to a new commit hash. But this approach protects you from automatically running new malicious code pushed to master/re-tagged.
- marcus_holmes 7y agoSorry, that whole github actions concept gives me the screaming heeby-jeebies. We're really not even pulling the dependency locally, we're just going to run someone else's code from their repo, on github's server, with our data and secrets? What could possibly go wrong with that? /s
- edaemon 7y agoThis isn't much different than other CI/CD pipelines. Docker images come to mind.
- marcosdumay 7y agoThis isn't much different than other SaaS CI/CD pipelines.
- jrochkind1 7y agoRight, such as travis, circleci, gitlab, etc. All of which are pretty popular, so clearly there is interest in SaaS CI/CD.
- marcosdumay 7y agoYes, they are popular. But on-premises ones also exist, are popular too, and mostly do not have this one problem. It's a relevant distinction on this context.
- deleted 7y ago[deleted]
- edaemon 7y agoOn-premise CI/CD may still (and often does) use someone else's code, which can expose data and secrets in the same way as outlined. The only difference is that it's on your own infrastructure. There's something to be said for on-premise solutions, but they won't save you from a malicious maintainer.
- bhouston 7y agoHow does this different from any other hosted CI/CD solution? I am thinking specifically about: * Gitlab's CI * CircleCI * TeamCity etc....
- sgarman 7y agoCan you give them read only access?
- boleary-gl 7y agoI think the main difference is actions is built around the idea of this ecosystem of "just include other people's code in your pipeline." With Team City or GitLab you're typically only running code you wrote in their respective configuration files. That's super valuable because you get started faster - e.g. "oh here's how I can deploy a lambda" but brings up this security concern of running other people's code. As discussed in the article, this is something NPM solved after the left-pad debacle. And I am sure (I hope) that GitHub will either change the documentation or add features to prevent this.
- unlinked_dll 7y agoif you're going to use memes in a blog post at least use them correctly
- shprink 7y agoWhat meme would you use then?
- unlinked_dll 7y agoInstead of an incorrectly applied tapping head meme I would have used the Big Brain meme to sarcastically suggest that using a package’s reported version on the marketplace was smarter than a git SHA
- bouke 7y agoI guess the same holds for Azure DevOps plugins, over which users don’t even have control over the version used. So what’s preventing plugin owners from doing something harmful?
- hn_throwaway_99 7y agoI think GitHub is making it extremely easy to make this mistake by making the Actions Marketplace so easily accessible when you're editing a workflow in their UI. This is horrible design. They should at least point out the real consequences of pulling in these other actions and letting you fork right there. I mean, there is an action in the marketplace that runs git-crypt to decrypt your files. With this issue, no user should ever be using this action without forking it to their repo first.
- wizzwizz4 7y agoIt's to reduce the friction to lock-in. GitHub should Just Work™, regardless if that sacrifices security, because the smoother the experience the more processes you'll build around it, so the harder it'll be to migrate away from it.
- miskander 7y agoMy team and I work on Actions at GitHub and I just wanted to stop by and add a bit more context. We definitely understand the concerns the article brings up and it's actually why we recommend in our documentation using SHA references when consuming third-party Actions. We also introduced the concept of verified Actions that extend an Organization's verification to Actions in the marketplace. We know there's more to do here to help prevent any malicious Actions and we're planning to continue to iterate. Thanks so much for the feedback and keep it coming.
- eximius 7y agoIt sounds like you should add an abstraction layer that makes the default depending on the SHA. Your product should be secure by default and it clearly is not right now. Likely, you can still do this and migrate people fairly painlessly to a secure version. Edit: even if you select a tag or something, it should use the underlying reference instead of the tag. You can add an escape hatch if you REALLY want to target the tag (there are obviously workflows where that makes sense), but it should be off by default and warm users of the security risks.
- dherman 7y agoI’m excited about Actions generally, so I’m glad to hear your team is aware of the challenges of building a reliable ecosystem of third party dependencies by reference to repos. Still, recommending git SHAs has real ergonomic and maintainability issues, and while it’s more defensive it doesn’t prevent left-pad style broken builds due to disappearing content. And at the same time, GitHub is investing heavily in package management infrastructure. I don’t say this lightly because designing good dependency management systems is much more subtle and difficult than people typically recognize, but from where I sit this appears to be fundamentally a dependency management concern. It seems a shame not to try to put GitHub Package Registry to good work here. Is that something potentially on the horizon?
- hn_throwaway_99 7y agoThis is an excellent point, and should solve the issue I put below about builds taking forever when pulling in a slow-building action. If I'm using a marketplace action in my workflow, I want "foo/action@v1.0.0" to be treated like a binary package dependency, not a build from sourcecode.
- paco_sinbad 7y agoWhat about hash collision? You could write an obfuscator to keep appending useless code or comments to the payload to continually generate commit hashes until you get a collision with the same original hash. A lot of work of course, and the hash is so f-ing huge it might take a few thousand compute-years, but you know, hackers find a way. If nothing else, use the full 40-char hash to ensure that your attacker has to find the same atom twice across 10 moons.
- nyxtom 7y agoLooks like you can now run actions on your own servers instead https://help.github.com/en/actions/automating-your-workflow-with-github-actions/hosting-your-own-runners https://help.github.com/en/actions/automating-your-workflow-... which might help with things quite a bit considering that you shouldn't have to expose any secrets if you are running them on your own machines
- wildpeaks 7y agoOne thing I'm missing from Actions is a way to manually trigger an action from the UI. Currently the closest equivalents are making a request via the API (but then you need a token with it, and all the security concerns it opens) or sending a special message using an empty commit (but I haven't found a simple way to do that from inside VSCode, unless I missed it somewhere).