8 ms·
A security vulnerability in Git that can lead to arbitrary code execution
- Foxboron 8y agoThe correct CVE numbers are CVE 2018-11233 and CVE 2018-11235. The microsoft blog mentions 11234, but thats not the git vulnerability.
- colemannugent 8y agoAnother reason to train yourself to always think before you execute code you found on a site. Too many of us are so used to git clone'ing a repo and building the software with make or its descendants that we overlook the security considerations.
- Someone1234 8y agoWouldn't that preclude the usage of npm almost entirely? npm from a security standpoint feels a little like a house of cards.
- Jeremy1026 8y agoUsing npm has never been secure, here is a fun little article about how someone used npm to inject malware into thousands of sites. https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5 https://hackernoon.com/im-harvesting-credit-card-numbers-and...
- nneonneo 8y agoThat’s a hypothetical piece (read it to the end), not the account of something that actually happened. Regardless, it still highlights the fact that everything is built on a rather fragile layer of trust.
- TooBrokeToBeg 8y agoNPM is still not secure. So dangerous, many companies run their own NPM repos with analyzed packages.
- da_chicken 8y agoI mean, there hasn't been anything as malicious as that, but... The left-pad issue [0] highlights how one developer can unpublish their code and result in breaking every package depended on that package. "Unpublish" can be substituted for anything from "unpublish" to "publish broken code" or "publish actively malicious code." Further, issues like the is-odd/is-even package popularity spike how developers can develop minimally beneficial encapsulation packages and then insert them into other packages as dependencies to pump up their numbers. [1] Well, what if someone's motivation wasn't to make their packages look important but to instead give them a way to inject code to all the locations (or maybe just one!) that run `npm update` or similar automatically on a daily basis. No, neither of these events that have actually happened are particularly malicious. On a scale of "excessive use of service" to "full network worm ransomware" they're somewhere around "suspiciously sketchy." But, the same problem can be exploited to cause real damage. Yeah, it very much reveals how fragile the web of trust in NPM is. I really do hate to keep posting these links, but people keep bringing NPM up where they're relevant! [0]: https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ [1]: https://www.reddit.com/r/programming/comments/886zji/why_has_there_been_nearly_3_million_installs_of/ https://www.reddit.com/r/programming/comments/886zji/why_has...
- koolba 8y ago> Too many of us are so used to git clone'ing a repo and building the software with make or its descendants that we overlook the security considerations. The issue here is that the "git clone ..." allows for arbitrary code execution so the flow of 1) clone 2) analyze 3) make breaks at step 1. Looks like it's back to tarballs for me.
- tetha 8y agoThis is going to be interesting for the go-guys, since a lot of go package management is built around git clones. It's probably fine for things hosted on gitlab, github or bitbucket, and then you missed that one sneaky little dependency stabbing you in the back.
- lolc 8y agoWhy is it more interesting for the go packaging situation? As far as I'm aware, most packaging systems run scripts from inside the packages anyway. If you're running the packages' scripts, being vulnerable to this is a side-note. You have to trust the packagers anyway.
- cesarb 8y agoFrom what I understood, it's only "git clone --recursive"/"git clone --recurse-submodules" or "git submodule init ..." that's vulnerable, not bare "git clone". So the flow of (1) clone (2) look at .gitmodules (3) git submodule init (4) analyze would still work.
- jacquesm 8y agoEven with tarballs all it takes is one fuck-up in a script and your homedirectory is gone. In that sense nothing is safe. You could of course audit all the code that the makefile or build script executes but I really don't know anybody that would do that for anything beyond the trivial. We've been totally conditioned to just wget some archive, unpack it and build it, and even if git clone takes it one step further in day-to-day practice there is no difference between the two.
- 8y ago
- empath75 8y agoPage is down -- anyone have a mirror?
- amaccuish 8y agohttps://webcache.googleusercontent.com/search?q=cache:CO48Rd83tw0J:https://blogs.msdn.microsoft.com/devops/2018/05/29/announcing-the-may-2018-git-security-vulnerability/+&cd=1&hl=en&ct=clnk&gl=uk https://webcache.googleusercontent.com/search?q=cache:CO48Rd...
- thomseddon 8y agohttp://webcache.googleusercontent.com/search?q=cache%3Ahttps%3A%2F%2Fblogs.msdn.microsoft.com%2Fdevops%2F2018%2F05%2F29%2Fannouncing-the-may-2018-git-security-vulnerability%2F&oq=cache%3Ahttps%3A%2F%2Fblogs.msdn.microsoft.com%2Fdevops%2F2018%2F05%2F29%2Fannouncing-the-may-2018-git-security-vulnerability%2F&aqs=chrome..69i57j69i58.1310j0j4&sourceid=chrome&ie=UTF-8 http://webcache.googleusercontent.com/search?q=cache%3Ahttps...
- hayanno 8y agohttps://webcache.googleusercontent.com/search?q=cache:CO48Rd83tw0J:https://blogs.msdn.microsoft.com/devops/2018/05/29/announcing-the-may-2018-git-security-vulnerability/+&cd=1&hl=fr&ct=clnk&gl=fr https://webcache.googleusercontent.com/search?q=cache:CO48Rd...
- AdmiralAsshat 8y agoSurely Microsoft should have enough resources to survive the usual HN-hug-of-death?
- reitanqild 8y agoMaybe HN, Reddit and /. struck at the same time?
- amaccuish 8y agoCached since I can't load the page: https://webcache.googleusercontent.com/search?q=cache:CO48Rd83tw0J:https://blogs.msdn.microsoft.com/devops/2018/05/29/announcing-the-may-2018-git-security-vulnerability/+&cd=1&hl=en&ct=clnk&gl=uk https://webcache.googleusercontent.com/search?q=cache:CO48Rd...
- feb 8y agoAnd the announcement from the Git project is at https://marc.info/?l=git&m=152761328506724&w=2 https://marc.info/?l=git&m=152761328506724&w=2. See also CVE-2018-11233 and 11235.
- deleted 8y ago[deleted]
- raesene9 8y agoSo to an extent, this is bad, you can be compromised by a malicious git repo, however given that most people already trust code cloned from git (or acquired from similarly untrusted sources like npm, rubygems, maven central etc) it may not change the equation that much. If you run code without trusting the author, you're likely going to have a bad time.
- ethomson 8y agoIt's not that you can be compromised by running the code contained in a git repository, it's that there's a bug that allows somebody to create a git repository that will cause you - merely by (recursively) cloning the repository - to run arbitrary code that they've provided. This is, of course, unexpected. And while you should perhaps raise an eyebrow if somebody you don't know asks you to recursively clone a repository that you're not interested in - this is indeed a problem and you should upgrade your Git client.
- raesene9 8y agoOh yeah I'm not saying don't upgrade, what I'm saying is that you're already cloning a repo. presumably to run the code therein. Given that running the code therein (if the owner of the repo. is malicious) will hurt you, this doesn't do too much apart from have it happen earlier on :) I guess one scenario where it could be a problem is if you were planning to clone untrusted code and read it all carefully before running it.
- phendrenad2 8y agoI’d guess that only 50% of times that people git pull a repo, they eventually execute it. I know that’s the figure for me personally - I pull a lot of projects down locally so i can open them in my IDE and study how they work - never to be executed.
- lazaroclapp 8y agoSuppose that you are, say, a security researcher, running purely static analysis tools on the code from every git repo that you can crawl, specifically looking for malware or common bugs without running the code (simple example: you are grep-ing for AWS keys and other secrets that should never be committed to a repo). This would be unexpected and very dangerous behavior in that setting. Sure, in theory, "unexpected and dangerous behavior" is par the course for security research and you isolate even data that you don't intend to execute if you suspect it is malicious. But, in practice, this is an easy mistake to make. As another example, consider an automatic git mirror, or whatever the internal GitHub/GitLab/Bitbucket infra might do to move repos around, without intending to execute the code.
- jancsika 8y agoWhat's a (common) example use case for a post-checkout hook?
- lainga 8y agoPulling a dependency project when a dependent project is checked out maybe
- ethomson 8y agoThat's a really interesting question. I tried to think about that when I was writing this blog post and couldn't really think about anything. Perhaps setting some permissions on a file or running `chattr` / `setfacl` is the best idea I had, but I omitted any suggestions because I've never actually used a post-checkout hook in anger.
- avar 8y agoThe post-checkout hook gets used for things like concatenating JS and CSS assets in a repository that's meant to house templates, i.e. a poor man's invocation of "make" whenever a user does a "git pull" without the user having to do anything extra. It can also be used for other cases where you'd like to amend what git does by default when updating the tree. See this recent thread[1] where some users want to have mtime behavior on files that's different from git's defaults, and one way to do that is via a post-checkout hook. 1. https://public-inbox.org/git/20180413170129.15310-1-mgorny@gentoo.org/ https://public-inbox.org/git/20180413170129.15310-1-mgorny@g...
- knodi123 8y agoI'm stretching here, but maybe compiling assets with webpack and then HUPing your web server? So when you switch between branches, your local server is always ready to serve up the version you've got on disk?
- berbec 8y agoI use a set of pre/post hooks to save uid & permission data for a repo that contains www & system data.
- 8y ago
- 0942v8653 8y agoPerhaps it would be best if sensitive options such as the post-checkout hook could only be stored outside of the repository altogether. Given this vulnerability and the semi-recent .GiT/config vulnerability[0], I would not be surprised if other attack vectors are lurking under the surface. Storing config data outside the repo would not be a foolproof solution, but it would probably make things a little safer. (Having the <repo_root>/.git folder has always felt a little bit "in-band" to me, and I don't like it.) [0]: https://news.ycombinator.com/item?id=8769667 https://news.ycombinator.com/item?id=8769667
- gitlab-security 8y agoThe monthly security release for GitLab was today, and this release was coordinated with the Git security release. https://about.gitlab.com/2018/05/29/security-release-gitlab-10-dot-8-dot-2-released/ https://about.gitlab.com/2018/05/29/security-release-gitlab-... In addition to our recently implemented monthly non-critical security release process (we already had a critical release process before), we are making a number of changes in how we secure GitLab.com, which includes expanding our HackerOne program this year to be a public bounty program. As always, we appreciate the contributions of security researchers.
- QuinnWilton 8y agoOver the past few years there's been a few vulnerabilities in Git that result from an attacker injecting hooks into a repo. I wonder whether it'd be possible / worthwhile to disable hooks by default, and only enable them on a per-repo basis. Of course, then the goal just becomes attacking that whitelist, and all the complexity that comes with that. Security is hard.
- chatmasta 8y agoA good starting point would be requiring a specific flag when executing any git command that should be attached to a hook. Something like git clone —-allow-hooks to enable post-checkout hooks ; or git commit —-allow-hooks to allow pre/post-commit hooks.
- peff 8y agoA few important points that aren't mentioned in the post: - you have to tell git to use submodules for this to trigger (so `clone --recurse-submodules` or a manual `git submodule update --init`) - credit for discovery goes to Etienne Stalmans, who reported it to GitHub's bug bounty program - most major hosters should prevent malicious repositories from being pushed up. This is actually where most of the work went. The fix itself was pretty trivial, but detection during push required a lot of refactoring. And involved many projects: I wrote the patches for Git itself, but others worked on libgit2, JGit, and VSTS.
- ethomson 8y agoThanks, peff, for the feedback. I pushed some changes to try to clarify that this does indeed require `clone --recursive`, and I added a note to credit Etienne Stalsman explicitly. That was an oversight in my haste.
- peff 8y agoNo problem! Thanks for all your work on this. I should have clarified above, too: there were folks from GitHub, Microsoft, and Google working on the various fixes.
- ethomson 8y agoThe Git community is great because even though many of the interested parties compete with each other in some form or another, we always put that aside. And that's especially true for security issues.
- avar 8y agoAnother thing not mentioned in the post, although admittedly more obscure, is that a 2.17.1 client will still happily ferry the evil objects along in its default configuration. I.e. in this sort of setup: unpatched hosting site -> in house (patched) v2.17.1 --bare mirror -> unpatched client The transfer.fsckObjects setting needs to be explicitly turned on for the in-house mirror so that it doesn't collude in passing the bad objects along from the unpatched hosting site. The protection in v2.17.1 only gets enabled by default if you're checking out a repository yourself, not if you're merely fetching and re-serving git objects[1]. Turning on receive.fsckObjects as the official v2.17.1 release notes suggest is not sufficient to protect against this attack. It needs to be transfer.fsckObjects, which also turns on fetch.fsckObjects, which is what's needed here. 1. https://public-inbox.org/git/20180529211950.26896-1-avarab@gmail.com/ https://public-inbox.org/git/20180529211950.26896-1-avarab@g...
- runesoerensen 8y agoThe initial Git for Windows 2.17.1 releases published on GitHub earlier today [0] apparently didn't include the patch. So just a heads up if you updated right after this was published: You probably want to make sure you have the fixed version (2.17.1.windows.2) [1] Not sure why the erroneous releases haven't been removed? Seems a bit confusing. [0] https://github.com/git-for-windows/git/releases/tag/v2.17.1.windows.1 https://github.com/git-for-windows/git/releases/tag/v2.17.1.... [1] https://github.com/git-for-windows/git/releases/tag/v2.17.1.windows.2 https://github.com/git-for-windows/git/releases/tag/v2.17.1....
- mappu 8y agoThe link on https://git-scm.com/ https://git-scm.com/ still points to the old 2.17.0. Chocolatey has the original 2.17.1, the 2.17.1-2 update is not yet approved. Cygwin still only has 2.17.0-1. I wonder whether they were even part of the embargo.
- runesoerensen 8y agoFor some reason git-scm.com is almost always slow at updating links to new Git for Windows releases. I usually just track the repository's atom feed [0] and download urgent updates directly from there (git-scm.com eventually links to the releases published on GitHub anyway). [0] https://github.com/git-for-windows/git/releases.atom https://github.com/git-for-windows/git/releases.atom Edit: The Git 2.17.1.2 Chocolatey package has now been approved https://chocolatey.org/packages/git/2.17.1.2 https://chocolatey.org/packages/git/2.17.1.2
- testplzignore 8y agoAm I the only one who didn't even know git submodules and recursive clones were a thing?
- jancsika 8y agoAfter reading the responses to my previous question, I'd like to know if there's a global way to turn off post-checkout hooks. None of the use-cases I read are convincing enough to allow `git clone` to do anything but what its short man description says. I'm not even thinking about security, just basic separation of concerns. If `git clone` leaves a script-hooked repo in an unusable state for building, I want to know up front so I can complain to the maintainer and get that problem fixed.
- ameliaquining 8y agoHooks aren't part of the repo. The only way your copy of a repo will have hooks is if you put them there.
- Piskvorrr 8y agoNot if you `git clone --recursive` an evil repo with anything < 2.17.1 (which is the point of the article and the reason of this discussion): then your copy will have hooks that you have not put in.
- chris_wot 8y agoWhat I really love about this is that they give details of the vulnerability. They never do this in any Microsoft security advisories. Guess when it's not your direct product this is OK.
- Froyoh 8y agoIt's probably not worth upgrading anyways.
- elfchief 8y agoWhat the link doesn't mention, that I can see, is what the first version affected was. Does this bug go back to the inroduction of submodules in git?
- jokoon 8y agoI'm sure there are security experts out there who managed to create tools that scans source code to find eventual security vulnerabilities. Although I'm not sure those tools could 'find' and build a vuln, but there could be ways to analyze an algorithm, and detect that it can do dangerous things it's not not supposed to do. A little like static analysis works. I'm sure those tools are already built by the NSA at least, so they just have to peek into github repos, point out what code is vulnerable, give it to some developer to make an exploit. Done. That way the NSA would clearly wins the cyber arms race, versus those pairs of eyes Torvalds was being quoted for, would surely be obsoleted.
- Vinnl 8y agoSee: https://testing.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html https://testing.googleblog.com/2016/12/announcing-oss-fuzz-c...
- lvangool 8y agoHmm - the "official" git PPA isn't updated yet: https://launchpad.net/~git-core/+archive/ubuntu/ppa https://launchpad.net/~git-core/+archive/ubuntu/ppa. Wonder if this due to dependencies or oversight?