Accidentally breaking GitHub Actions with a shorthash collision (2019)
https://blog.teddykatz.com/2019/11/12/github-actions-dos.html
Automated Summary
The article discusses the discovery and exploitation of a security issue in GitHub Actions, a workflow automation tool integrated with GitHub. The author created a configuration file for GitHub Actions to execute a script (foo.sh) in a Docker container when a comment is added to an issue. The configuration file included a reference to a specific commit (76ff57a) of a GitHub repository (actions/docker) for setting up a Docker container. The author noticed that this commit hash was an abbreviated shorthash, which could potentially lead to a collision and break the build in the future. By generating such a collision, the author was able to cause a denial-of-service (DoS) on GitHub Actions builds globally. This incident led to improvements in the GitHub Actions config wizard to generate full 40-character commit hashes in config files.
I'd simplify the guidance on using full/short hashes to:
* Automated use? Always use full hashes
* Human use? Short hashes are usually fine, but a full hash doesn't hurt (and please make it available in a link/hovertext)
I'd simplify the guidance even more: short hashes are fine if and only if the repository hasn't been modified since they were generated (AFAIK, git automatically increases the length of the short hash it displays whenever it would otherwise cause a collision).
I'm not sure that's necessarily practical though - if I'm dropping a link in Slack to a colleague
> You want to look at [a123456](some.git.url/a12345678...) to see where we've done this before
I can't promise that the repo won't have changed by the time they look at it (but because the full hash is linked, it's not a problem in practice).
(2019), while Actions was in beta using a different syntax. Might still be interesting to read though.
> To get the collision to affect anything on GitHub, I needed to push it to the actions/docker repo. This posed a problem, because I didn’t have write access to the actions/docker repo. However, I realized I could get around that issue by forking the actions/docker repo and pushing a commit to my fork (since GitHub shares commits between forks and parent repositories).
It does what?!?!
So if i have a repo which does not contain commit abcdef, and some random evil bastard forks it, and adds a commit abcdef, then users can ask for commit abcdef from my repository, and get the commit the evil guy added? That seems surprising and bad!
I tried it (with short/full commit hash). GitHub gives a warning:
> This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
I remember when GitHub actions was based on HCL. They switched to YAML pretty quickly and have never talked much about why.
I always thought HCL was a fairly smart/interesting choice, and I’ve always wondered if they backed out because users were unfamiliar with HCL, the ecosystem wasn’t ready for HCL, or something else.
It doesn't seem to have been mentioned in this article, but AFAIK git detects when a collision happens, and automatically generates a longer shorthash for that commit. Of course, that doesn't fix shorthashes generated before the colliding object was added.
From the same author: https://github.com/not-an-aardvark/lucky-commit a tool for generating commits with specific shorthashes.
Thank you for a very detailed write up. Here I am using shorthash for Docker image tags. I guess I will fix this asap.
Ideally Docker would support a lockfile format so you don't have to manually manage the hashes. I'm still surprised how commonly people use named Docker tags when Docker Hub let's you mutate the corresponding image.
In the meantime, the article is right that you should use the full-length digests for situations where you care about reproducibility.
Anytime you run apt install/apk install, your Docker image became unreproducible. I mainly use shorthash for easy manual inspection. The Dockerhub is set to clean up images older than 2 months so the risk if shorthash collision is very low (but not impossible)
Is anyone actually building more on Microsoft services? I have been withdrawing as much stuff as possible from anything Microsoft owns.
The writing is on the wall with their abuse of customers on Windows 11.
Microsoft gives me AOL vibes, where the ancient customers will be squeezed until the end.
This needs a [2019] in the title.
(2019)