{"thread":{"id":"53894","subject":"Disclosure - Git Packs (zlib) Allows for Zipbomb Style Attacks","startedAt":"2020-07-21T19:31:58Z","lastAt":"2020-07-21T23:42:51Z","messageCount":2,"participants":["Matt Parnell","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"401817","messageId":"eafc4ebc-47dd-8f7a-d201-74e5369014d1@gmail.com","threadId":"53894","inReplyTo":null,"subject":"Disclosure - Git Packs (zlib) Allows for Zipbomb Style Attacks","fromName":"Matt Parnell","fromEmail":"mparnell@gmail.com","sentAt":"2020-07-21T19:31:48Z","receivedAt":"2020-07-21T19:31:58Z","isPatch":false,"sender":{"key":"mparnell@gmail.com","avatar":null},"body":"Description:\n\nUsing compression friendly files, in this case, multiple 99MB zero byte\nfilled files, a prankster or malicious actor in control of a popular\nrepository can cause all who clone or pull a given branch to take up far\nmore storage locally than displayed remotely on the git host - this is\nnot limited to GitHub, but would apply to literally any git host,\nincluding just git+ssh.\nMy Example Repo: https://github.com/ilikenwf/git-zlib-bomb\n\nThe size of the repo on GitHub and my local git server is 744K, while\nthe non-mirrored, cloned version with extracted objects is around 101GB.\n\nI argue this is a bit different than the \"git bomb\" by GitHub user\nKatee, as hers was more focused on recursion and segfaults. In this\ncase, the attack focuses on git's use of zlib to compress the packs,\nespecially since it will store only one compressed copy of an\nobject/file in the repo, even if multiple copies of it exist.\n\nWhile Github does already abort pushes when it detects files over 100MB,\nand warn for files below that size, it doesn't seem to investigate\ncumulative size of the extracted pack on disk. Even so, this doesn't\nreally help with git itself, the application, as it means that hosts and\nusers elsewhere are still in danger and the only way to mitigate that I\ncan think of would be to have git store a cumulative size value that can\nbe used for warnings, or perhaps some logic that detects zero or\nrepetitively filled files that compress in a deceptive manner.\nSteps To Reproduce:\n\n(Add details for how we can reproduce the issue)\n\n    Create a new repo locally.\n    Create multiple 1MB to 99MB zero filled files in the repo to get a\ntotal in the tens or hundreds of gigabytes, or beyond. I just used\n\nfor i in $(seq 1 1035); do dd if=/dev/zero of=test$i bs=99M count=1; done\n\n    Add them all to the repo and commit.\n    Push them to a remote git server, or clone them as only a mirror.\n    Compare the disk space utilized between the original repo, and the\nmirrored repo.\n\nImpact\n\nWhile this does not give unauthorized access to an attacker, it could be\nused to easily consume a large amount of any given developer's time and\nstorage space. I personally would be very angry if I took the time to\nclone a repo, only to have it crash when it ran out of space, or occupy\nhundreds or thousands of gigabytes.\n\nMy quick and dirty way of doing this could still be abused further, with\na purpose built tool that adds objects to the pack on the fly, avoiding\nthe need for disk space to stage our zero filled files onto, making for\neven larger repositories, that are deceptively small in size on the\nserver/mirror side.\nSuggested Mitigation\nConsidering this particular issue, along with that by Kattee\n(https://github.com/Katee/git-bomb), I think it would be beneficial to\nat the least check the repo/clone/fetch size and warn if the target\nlocation is not large enough, or if the repo is exorbitantly large.\n\n"},{"id":"401836","messageId":"20200721234210.GB1667453@crustytoothpaste.net","threadId":"53894","inReplyTo":"eafc4ebc-47dd-8f7a-d201-74e5369014d1@gmail.com","subject":"Re: Disclosure - Git Packs (zlib) Allows for Zipbomb Style Attacks","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-07-21T23:42:10Z","receivedAt":"2020-07-21T23:42:51Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-07-21 at 19:31:48, Matt Parnell wrote:\n> Description:\n> \n> Using compression friendly files, in this case, multiple 99MB zero byte\n> filled files, a prankster or malicious actor in control of a popular\n> repository can cause all who clone or pull a given branch to take up far\n> more storage locally than displayed remotely on the git host - this is\n> not limited to GitHub, but would apply to literally any git host,\n> including just git+ssh.\n> My Example Repo: https://github.com/ilikenwf/git-zlib-bomb\n> \n> The size of the repo on GitHub and my local git server is 744K, while\n> the non-mirrored, cloned version with extracted objects is around 101GB.\n> \n> I argue this is a bit different than the \"git bomb\" by GitHub user\n> Katee, as hers was more focused on recursion and segfaults. In this\n> case, the attack focuses on git's use of zlib to compress the packs,\n> especially since it will store only one compressed copy of an\n> object/file in the repo, even if multiple copies of it exist.\n> \n> While Github does already abort pushes when it detects files over 100MB,\n> and warn for files below that size, it doesn't seem to investigate\n> cumulative size of the extracted pack on disk. Even so, this doesn't\n> really help with git itself, the application, as it means that hosts and\n> users elsewhere are still in danger and the only way to mitigate that I\n> can think of would be to have git store a cumulative size value that can\n> be used for warnings, or perhaps some logic that detects zero or\n> repetitively filled files that compress in a deceptive manner.\n> Steps To Reproduce:\n> \n> (Add details for how we can reproduce the issue)\n> \n>     Create a new repo locally.\n>     Create multiple 1MB to 99MB zero filled files in the repo to get a\n> total in the tens or hundreds of gigabytes, or beyond. I just used\n> \n> for i in $(seq 1 1035); do dd if=/dev/zero of=test$i bs=99M count=1; done\n> \n>     Add them all to the repo and commit.\n>     Push them to a remote git server, or clone them as only a mirror.\n>     Compare the disk space utilized between the original repo, and the\n> mirrored repo.\n> \n> Impact\n> \n> While this does not give unauthorized access to an attacker, it could be\n> used to easily consume a large amount of any given developer's time and\n> storage space. I personally would be very angry if I took the time to\n> clone a repo, only to have it crash when it ran out of space, or occupy\n> hundreds or thousands of gigabytes.\n\nI agree this is inconvenient, but it's a problem that occurs with all\ncompression.  Literally any zip file or tarball can have this problem as\nwell, and those are other formats customarily used for software\ninterchange.\n\nI don't think this is a security problem because it's a known attribute\nof compression which is endemic to all compressed data.  We don't\nconsider the zip, gzip, and xz programs to have security vulnerabilities\nbecause they don't limit the size of the data they uncompress.\n\nThere are cases where this _is_ a vulnerability, usually where some\nlarger system fails because an attacker can feed it data and make it run\nout of resources.  If you're developing such a system, then you\ndefinitely need to use a dedicated user with quotas or a limited-size\noverly (e.g., Docker) to restrict against exhausting resources, but you\nneed to do that anyway, independent of whether you're using Git.  So I\ndon't consider this to intrinsically be a security problem in Git any\nmore than it is in other general-purpose tools that uncompress data.\n-- \nbrian m. carlson: Houston, Texas, US\n"}]}