Description: Using compression friendly files, in this case, multiple 99MB zero byte filled files, a prankster or malicious actor in control of a popular repository can cause all who clone or pull a given branch to take up far more storage locally than displayed remotely on the git host - this is not limited to GitHub, but would apply to literally any git host, including just git+ssh. My Example Repo: https://github.com/ilikenwf/git-zlib-bomb The size of the repo on GitHub and my local git server is 744K, while the non-mirrored, cloned version with extracted objects is around 101GB. I argue this is a bit different than the "git bomb" by GitHub user Katee, as hers was more focused on recursion and segfaults. In this case, the attack focuses on git's use of zlib to compress the packs, especially since it will store only one compressed copy of an object/file in the repo, even if multiple copies of it exist. While Github does already abort pushes when it detects files over 100MB, and warn for files below that size, it doesn't seem to investigate cumulative size of the extracted pack on disk. Even so, this doesn't really help with git itself, the application, as it means that hosts and users elsewhere are still in danger and the only way to mitigate that I can think of would be to have git store a cumulative size value that can be used for warnings, or perhaps some logic that detects zero or repetitively filled files that compress in a deceptive manner. Steps To Reproduce: (Add details for how we can reproduce the issue) Create a new repo locally. Create multiple 1MB to 99MB zero filled files in the repo to get a total in the tens or hundreds of gigabytes, or beyond. I just used for i in $(seq 1 1035); do dd if=/dev/zero of=test$i bs=99M count=1; done Add them all to the repo and commit. Push them to a remote git server, or clone them as only a mirror. Compare the disk space utilized between the original repo, and the mirrored repo. Impact While this does not give unauthorized access to an attacker, it could be used to easily consume a large amount of any given developer's time and storage space. I personally would be very angry if I took the time to clone a repo, only to have it crash when it ran out of space, or occupy hundreds or thousands of gigabytes. My quick and dirty way of doing this could still be abused further, with a purpose built tool that adds objects to the pack on the fly, avoiding the need for disk space to stage our zero filled files onto, making for even larger repositories, that are deceptively small in size on the server/mirror side. Suggested Mitigation Considering this particular issue, along with that by Kattee (https://github.com/Katee/git-bomb), I think it would be beneficial to at the least check the repo/clone/fetch size and warn if the target location is not large enough, or if the repo is exorbitantly large.
Attachment:
signature.asc
Description: OpenPGP digital signature
