{"thread":{"id":"36078","subject":"Trust issues with hooks and config files","startedAt":"2014-03-06T21:47:43Z","lastAt":"2014-03-16T13:45:45Z","messageCount":5,"participants":["Julian Brost","Jeff King","Junio C Hamano","Sitaram Chamarty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"236207","messageId":"5318ECFF.40908@0x4a42.net","threadId":"36078","inReplyTo":null,"subject":"Trust issues with hooks and config files","fromName":"Julian Brost","fromEmail":"julian@0x4a42.net","sentAt":"2014-03-06T21:47:43Z","receivedAt":"2014-03-06T21:47:43Z","isPatch":false,"sender":{"key":"julian@0x4a42.net","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\nHi,\n\nI've noticed some behavior of git that might lead to some security\nissues if the user is not aware of this.\n\nAssume we have an evil user on a system, let's call him eve. He\nprepares a repository where he allows other user to push changes to.\nIf he now adds a post-receive hook, git will happly execute it as\nwhatever user pushes to this repository:\n\n  root@argon /tmp/git-eve # ls -l /tmp/git-eve/hooks/post-receive\n  -rwxr-xr-x 1 eve users [...] /tmp/git-eve/hooks/post-receive\n  root@argon /tmp/git-root # cat /tmp/git-eve/hooks/post-receive\n  #!/bin/sh\n  id\n  root@argon /tmp/git-root # git push /tmp/git-eve master\n  Counting objects: 3, done.\n  Writing objects: 100% (3/3), 185 bytes | 0 bytes/s, done.\n  Total 3 (delta 0), reused 0 (delta 0)\n  remote: uid=0(root) gid=0(root) groups=0(root),[...]\n  To /tmp/git-eve\n   * [new branch]      master -> master\n\nSomething similiar might happen if eve adds some alias to the config\nfile in the repository and grants any other user read access to the\nrepository. These aliases will be executed when some other user is\nrunning any git command in this repository. Even though git does not\nallow defining aliases for existing commands, you might mistype\nsomething, so adding an alias for \"lg\" instead of \"log\" might succeed:\n\n  root@argon /tmp/git-eve # ls -l /tmp/git-eve/config\n  -rw-r--r-- 1 eve users [...] /tmp/git-eve/config\n  root@argon /tmp/git-eve # cat config\n  [core]\n  \trepositoryformatversion = 0\n  \tfilemode = true\n  \tbare = true\n  [alias]\n  \tlg = !id\n  root@argon /tmp/git-eve # git lg\n  uid=0(root) gid=0(root) groups=0(root),[...]\n\nThis gets even worse if you know something about the aliases your\nvictim uses, so for example you can override an alias 'l = log'\ndefined in the user's config with something malicious in the\nrepository config file.\n\nI'd suggest taking a similar approach as Mercurial [1], i.e. ignoring\nconfiguration files and hooks owned by another user unless the owner\nis explicitly trusted.\n\nRegards,\nJulian\n\n[1] http://mercurial.selenic.com/wiki/Trust\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v2.0.22 (GNU/Linux)\n\niQIcBAEBCAAGBQJTGOz5AAoJECLcYT6QIdBtJLEP/1VPMyRws5IYOVXJDcLukxkh\n87RuL6ZCXE9v66VgEmTYYtJx1Umy18YXCx+ufAuJL2xzo/QH/QhWl/npa+U3ac7D\n2A/3rXt1PvdzoQeT3514t5ntO9WyquHE2N8Ix+xdxwFo/T+Ve+nDV8/hra9he1Nb\nzdldBccyHBDQdEudBLs6tDoJU9fvQ4TAGCGw7CXHCDV4hhyXHt8Nyf9nNOWxXgYh\n5QcDs0sj1MCFm5AdN1SOU7FobiwS//Q8QdKdr9O6L18IoUPnSw2a1S2hGJmwQ/IL\nY1nQMdFuSx+4n6KKgUBtlo4WTi38u98FG4N0MXqZOSX7SKDVEOYfF+1W31Trhtuw\nKMtojlwBYXsq0CWrW1OQ4Oed91lDGBtLLzF8MSCN1NoG4+Eb/V+RueLzulC5lWU/\nIpDr3d14vFBEydHzYY+35P57Rf2Fl5HkXLQzQ0UmROeAmhUVCnduRj4dn35nb47Z\nG/73UdgX1FMB4lOD8kD9KX0Sov3XLz4n5u706h+lElapd24wBXlaysWVpsmImuW0\nxPLSpX0Dfrtj0sOCvqM0oX40z3bCJ1ibqZOmPGwF0P66DJOOq9sqDYfHlgnvt/qU\npCqsy0+FyCUuGP17UliEWcFAfdzXrUhxkRneQXC8ieX8YSoP4OtjzIPHrsc54s/2\n7VR0wCTxaHvd05T8WruK\n=kc4p\n-----END PGP SIGNATURE-----\n"},{"id":"236274","messageId":"20140307210403.GA6790@sigill.intra.peff.net","threadId":"36078","inReplyTo":"5318ECFF.40908@0x4a42.net","subject":"Re: Trust issues with hooks and config files","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-03-07T21:04:04Z","receivedAt":"2014-03-07T21:04:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 06, 2014 at 10:47:43PM +0100, Julian Brost wrote:\n\n> I've noticed some behavior of git that might lead to some security\n> issues if the user is not aware of this.\n> \n> Assume we have an evil user on a system, let's call him eve. He\n> prepares a repository where he allows other user to push changes to.\n> If he now adds a post-receive hook, git will happly execute it as\n> whatever user pushes to this repository:\n\nYes, this is a well-known issue. The only safe operation on a repository\nfor which somebody else controls hooks and config is to fetch from it\n(upload-pack on the remote repository does not respect any dangerous\nconfig or hooks).\n\n> Something similiar might happen if eve adds some alias to the config\n> file in the repository and grants any other user read access to the\n> repository. These aliases will be executed when some other user is\n> running any git command in this repository. Even though git does not\n> allow defining aliases for existing commands, you might mistype\n> something, so adding an alias for \"lg\" instead of \"log\" might succeed:\n\nMuch easier is to define an external diff or textconv tool; then the\nvictim does not even have to typo.\n\n> I'd suggest taking a similar approach as Mercurial [1], i.e. ignoring\n> configuration files and hooks owned by another user unless the owner\n> is explicitly trusted\n\nIt has been discussed, but nobody has produced patches. I think that\nnobody is really interested in doing so because:\n\n  1. It introduces complications into previously-working setups (e.g., a\n     daemon running as \"nobody\" serving repos owned by a \"git\" user\n     needs to mark \"git\" as trusted).\n\n  2. In most cases, cross-server boundaries provide sufficient\n     insulation (e.g., I might not push to an evil person's repo, but rather\n     to a shared repo whose hooks and config are controlled by root on\n     the remote server).\n\nIf you want to work on it, I think it's an interesting area. But any\ndevelopment would need to think about the transition plan for existing\nsites that will be broken.\n\nAt the very least, the current trust model could stand to be documented\nmuch better (I do not think the rule of \"fetching is safe, everything\nelse is not\" is mentioned anywhere explicitly).\n\n-Peff\n"},{"id":"236342","messageId":"531CA468.3060604@0x4a42.net","threadId":"36078","inReplyTo":"20140307210403.GA6790@sigill.intra.peff.net","subject":"Re: Trust issues with hooks and config files","fromName":"Julian Brost","fromEmail":"julian@0x4a42.net","sentAt":"2014-03-09T17:27:04Z","receivedAt":"2014-03-09T17:27:04Z","isPatch":false,"sender":{"key":"julian@0x4a42.net","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\nOn 07.03.2014 22:04, Jeff King wrote:\n> Yes, this is a well-known issue. The only safe operation on a\n> repository for which somebody else controls hooks and config is to\n> fetch from it (upload-pack on the remote repository does not\n> respect any dangerous config or hooks).\n\nI'm a little bit surprised that you and some other people I asked see\nthis as such a low-priority problem as this makes social engineering\nattacks on multi-user systems, like they are common at universities,\nreally easy (this is also how I noticed the problem).\n\n> It has been discussed, but nobody has produced patches. I think\n> that nobody is really interested in doing so because:\n> \n> 1. It introduces complications into previously-working setups\n> (e.g., a daemon running as \"nobody\" serving repos owned by a \"git\"\n> user needs to mark \"git\" as trusted).\n> \n> 2. In most cases, cross-server boundaries provide sufficient \n> insulation (e.g., I might not push to an evil person's repo, but\n> rather to a shared repo whose hooks and config are controlled by\n> root on the remote server).\n> \n> If you want to work on it, I think it's an interesting area. But\n> any development would need to think about the transition plan for\n> existing sites that will be broken.\n\nI can understand the problem with backward compatibility but in my\nopinion the default behavior should definitely be to ignore untrusted\nconfig files and hooks as it would otherwise only protect users that\nare already aware of the issue anyways and manually enable this option.\n\nAre there any plans for some major release in the future that would\nallow introducing backward incompatible changes?\n\nI would definitely spend some time working on a patch but so far I\nhave no idea of git's internals and never looked at the source before.\n\n> At the very least, the current trust model could stand to be\n> documented much better (I do not think the rule of \"fetching is\n> safe, everything else is not\" is mentioned anywhere explicitly).\n\nGood point but not enough in my opinion as I haven't read every git\nmanpage before running it for the first time.\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v2.0.22 (GNU/Linux)\n\niQIcBAEBCAAGBQJTHKRfAAoJECLcYT6QIdBtGdkQALD24YhS2aHBzi/c6a/1+eOC\nxERUshDJvU/3picpTqqwFlqHB6X53vo7uXcCmJU8oaMsGLeLrTyrX77YOzrhlkuK\nkERkXGPgyoW1G4enATSURDbjW6kp7SG0lRvGTPNySqDt9FiZYTDP7CGsQRDDl8cL\nal50BoNFsx9K/kiPgbDJsenDi/MAclAYlHbHJnEB6aBo06G89zwC2tECFtXewnAD\nEbCKPI4tFrUZW/rWxHAEDVs+cI038nMzSNMi7I+HAMG48s+iMfFF69pkdOQjhIsc\n3irisLQcKPVNRjSK/dGEKbqkAy9wziNza69tl0EgQn6ewju5NZ4xbAkWQG9LEWfZ\nUx1safkumQsAKiYfn87t5YDXZ3vDYKbChKQv/UlicobVRm0YbhitY2AQAzu+wx1V\nmXmG6D91IxfR4B0+AA+3/E8huSD4JJ2laIUwIoYV+y4+ZAlxnT4cNdYiYAH4oEme\nwZ9R0wsxVfUm+uFdSBqsgEpv7Bp9PRcREuVXXz0GQH0wQ8zdwOeeNvA3v6ZtodRZ\n0q7WOVJpd/3j4fQoWUXFAOZxDIZVorM0dQQvbhXiwOE9UY5Gwpq22lGKHM1t+8EO\nlOUCQBXjscfPgyLifdSbnaf11RGgVLERQlpz6hpEGht1J3AqF6tTZPjto+iVV97v\nnObYVtMXsAtrKbka2FF+\n=ps1M\n-----END PGP SIGNATURE-----\n"},{"id":"236408","messageId":"xmqqiormrsjh.fsf@gitster.dls.corp.google.com","threadId":"36078","inReplyTo":"531CA468.3060604@0x4a42.net","subject":"Re: Trust issues with hooks and config files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-10T15:18:26Z","receivedAt":"2014-03-10T15:18:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Julian Brost <julian@0x4a42.net> writes:\n\n> On 07.03.2014 22:04, Jeff King wrote:\n>> \n>> If you want to work on it, I think it's an interesting area. But\n>> any development would need to think about the transition plan for\n>> existing sites that will be broken.\n>\n> I can understand the problem with backward compatibility but in my\n> opinion the default behavior should definitely be to ignore untrusted\n> config files and hooks as it would otherwise only protect users that\n> are already aware of the issue anyways and manually enable this option.\n>\n> Are there any plans for some major release in the future that would\n> allow introducing backward incompatible changes?\n\nGit 2.0 has been in the planning for quite some months, and I am\ninclined to merge these topics prepared for that release to 'master'\nduring this cycle.  Anything new like this one is way too late for\nit, but that does not mean we can never do 3.0 in the future.\n\nPerhaps going this way might be possible:\n\n * Introduce a configuration that is read only from $HOME/.gitconfig\n   (or its xdg equivalent) to enable or disable the \"unsafe\" behaviour.\n\n   By default (i.e. when the above configuration is not set), allow\n   \"unsafe\" read; when instructed by the above configuration to\n   forbid \"unsafe\" read, ignore configuration files that are not\n   owned by the owner of the process.  People can toggle the\n   \"unsafe\" read to experiment with the above (~gitdaemon/.gitconfig\n   can perhaps be used to restrict the daemon access)\n\n   Keep it that way for a few releases.\n\n * After a few releases, start warning people who do not have the\n   \"unsafe\" option in their $HOME/.gitconfig about a future default\n   change, to force them to explicitly set it.\n\n   Keep it that way for a few releases.\n\n * Flip the default, perhaps still keeping the warning on the\n   flipped default to help people who have not been following along.\n\n   Keep it that way for a few releases.\n\n * Then finally remove the warning.\n\nA release cycle usually last 10-12 weeks on average.\n"},{"id":"236835","messageId":"5325AB09.4080705@gmail.com","threadId":"36078","inReplyTo":"531CA468.3060604@0x4a42.net","subject":"Re: Trust issues with hooks and config files","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2014-03-16T13:45:45Z","receivedAt":"2014-03-16T13:45:45Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 03/09/2014 10:57 PM, Julian Brost wrote:\n> On 07.03.2014 22:04, Jeff King wrote:\n>> Yes, this is a well-known issue. The only safe operation on a\n>> repository for which somebody else controls hooks and config is to\n>> fetch from it (upload-pack on the remote repository does not\n>> respect any dangerous config or hooks).\n>\n> I'm a little bit surprised that you and some other people I asked see\n> this as such a low-priority problem as this makes social engineering\n> attacks on multi-user systems, like they are common at universities,\n> really easy (this is also how I noticed the problem).\n\nThis, and a lot more control related issues, are solved by tools like\ngitolite (which I maintain) and Gerrit (from Google), and also many GUI\nbased access control tools like gitlab, gitorious, etc.\n\nIn these schemes the user does not have a \"unix\" account on the server,\nand any hooks that run will run as the \"hosting user\".  Access is either\nvia ssh pub keys (most commonly) or http auth.\n\nIt is my belief that most multi-user systems have installed one of these\nsystems, and therefore the situation you speak of does not arise.  They\nprobably didn't install them to solve *this* problem, but to keep some\nsemblance of control over who can access what repo, but as a side-effect\nthey solve this problem also.\n\nsitaram\n\n>> It has been discussed, but nobody has produced patches. I think\n>> that nobody is really interested in doing so because:\n>\n>> 1. It introduces complications into previously-working setups\n>> (e.g., a daemon running as \"nobody\" serving repos owned by a \"git\"\n>> user needs to mark \"git\" as trusted).\n>\n>> 2. In most cases, cross-server boundaries provide sufficient\n>> insulation (e.g., I might not push to an evil person's repo, but\n>> rather to a shared repo whose hooks and config are controlled by\n>> root on the remote server).\n>\n>> If you want to work on it, I think it's an interesting area. But\n>> any development would need to think about the transition plan for\n>> existing sites that will be broken.\n>\n> I can understand the problem with backward compatibility but in my\n> opinion the default behavior should definitely be to ignore untrusted\n> config files and hooks as it would otherwise only protect users that\n> are already aware of the issue anyways and manually enable this option.\n>\n> Are there any plans for some major release in the future that would\n> allow introducing backward incompatible changes?\n>\n> I would definitely spend some time working on a patch but so far I\n> have no idea of git's internals and never looked at the source before.\n>\n>> At the very least, the current trust model could stand to be\n>> documented much better (I do not think the rule of \"fetching is\n>> safe, everything else is not\" is mentioned anywhere explicitly).\n>\n> Good point but not enough in my opinion as I haven't read every git\n> manpage before running it for the first time.\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n\n\n"}]}