{"thread":{"id":"2155","subject":"The git protocol and DoS","startedAt":"2005-10-19T20:00:05Z","lastAt":"2005-10-20T08:16:45Z","messageCount":12,"participants":["H. Peter Anvin","Junio C Hamano","Linus Torvalds","Petr Baudis","Tony Luck","David Brown","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"10292","messageId":"4356A5C5.5080905@zytor.com","threadId":"2155","inReplyTo":null,"subject":"The git protocol and DoS","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-19T20:00:05Z","receivedAt":"2005-10-19T20:00:05Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"I've been concerned for a while that the git protocol may be inherently \nvulnerable to a \"SYNful DoS\" attack (spraying raw TCP SYN packets with \nenough data to start substantial server activity.) Although SYN cookies \nprotect against this to some degree, it makes me wonder if something \nshould be added to the protocol itself.\n\nOne way to do this would be to start the transaction by having the \nserver transmit a cookie to the client, and to require the client to \nsend a SHA1 of the (cookie + request) together with the request. This \nwould be done with a fairly short timeout.\n\nIt would, however, require a protocol change; I would like to hear what \npeople think about this at this stac=ge.\n\n\t-hpa\n"},{"id":"10297","messageId":"7vmzl544f3.fsf@assigned-by-dhcp.cox.net","threadId":"2155","inReplyTo":"4356A5C5.5080905@zytor.com","subject":"Re: The git protocol and DoS","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-19T20:50:40Z","receivedAt":"2005-10-19T20:50:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" writes:\n\n> It would, however, require a protocol change; I would like to hear what \n> people think about this at this stac=ge.\n\nWell, it is full two days since a majorly visible git protocol\nenabled server has been announced, and you probably know what\nkind of hits you are getting (and please let us know if you have\nnumbers, I am curious). If we do a protocol change, earlier the\nbetter. You already said that the kernel.org git is\nexperimental. Does anybody run git daemons and rely on the\ncurrent protocol?\n\nI suspect it would not make *any* sense to have a backward\ncompatible server that optionally allows this cookie exchange --\nattackers can just say \"I am an older client\". OTOH, it\nprobably makes sense to have an option on the client side to\nskip the cookie exchange stage. I do not think autodetecting\nnew/old server on the client side in connect.c is possible.\n"},{"id":"10298","messageId":"4356B2C7.601@zytor.com","threadId":"2155","inReplyTo":"7vmzl544f3.fsf@assigned-by-dhcp.cox.net","subject":"Re: The git protocol and DoS","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-19T20:55:35Z","receivedAt":"2005-10-19T20:55:35Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \"H. Peter Anvin\" writes:\n> \n>>It would, however, require a protocol change; I would like to hear what \n>>people think about this at this stac=ge.\n> \n> Well, it is full two days since a majorly visible git protocol\n> enabled server has been announced, and you probably know what\n> kind of hits you are getting (and please let us know if you have\n> numbers, I am curious).\n\nAbout 350 hits so far, total. Utter peanuts.\n\n> If we do a protocol change, earlier the\n> better. You already said that the kernel.org git is\n> experimental. Does anybody run git daemons and rely on the\n> current protocol? \n >\n> I suspect it would not make *any* sense to have a backward\n> compatible server that optionally allows this cookie exchange --\n> attackers can just say \"I am an older client\". OTOH, it\n> probably makes sense to have an option on the client side to\n> skip the cookie exchange stage. I do not think autodetecting\n> new/old server on the client side in connect.c is possible.\n> \n\nYou mean an option on the *server* to skip the cookie exchange? If so, \nhow would you expect the client to handle it?\n\n\t-hpa\n"},{"id":"10301","messageId":"7vek6h43oj.fsf@assigned-by-dhcp.cox.net","threadId":"2155","inReplyTo":"4356B2C7.601@zytor.com","subject":"Re: The git protocol and DoS","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-19T21:06:36Z","receivedAt":"2005-10-19T21:06:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" writes:\n\n> You mean an option on the *server* to skip the cookie exchange? If so, \n> how would you expect the client to handle it?\n\nNo, what I was thinking was to tell the client \"you will be\ntalking to an old server, so do not try to read that cookie and\nget stuck\".\n"},{"id":"10305","messageId":"Pine.LNX.4.64.0510191410570.3369@g5.osdl.org","threadId":"2155","inReplyTo":"4356B2C7.601@zytor.com","subject":"Re: The git protocol and DoS","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-19T21:31:47Z","receivedAt":"2005-10-19T21:31:47Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 19 Oct 2005, H. Peter Anvin wrote:\n> \n> You mean an option on the *server* to skip the cookie exchange? If so, how\n> would you expect the client to handle it?\n\nHey guys, I actually planned for the protocol to be extensible.\n\nThe client always starts out by sending the \"command\" first, and if you \nwant to add a challenge-response thing, I really think you should make it \na nice compatible upgrade (and then later on, you can have a server option \nthat says \"if the client doesn't do the challenge-response version, I \nwon't talk to him\").\n\nBasically, right now the client sends a\n\n\t\"git-upload-pack /absolute/pathname/to/repo\"\n\nover the protocol, and the whole point of this was that (a) it's \nextensible and (b) the server knows what to expect, and can close the \nsocket if it doesn't get a valid packet.\n\nSo if you add some extra challenge-response thing, please just do so by \nchanging the string. Teach the server to also accept\n\n\t\"git-upload-pack --challenge /absolute/pathname/to/repo\"\n\nfor example. Then later, add a \"secure server\" mode that refuses to do the \nold non-challenge response.\n\nHOWEVER. The server _already_ has some of this logic: if you start it \noutside of inetd, it will start killing its own children when there are \ntoo many of them, but it will start by sending them a SIGTERM. And the \ngit-daemon code is set up so that a SIGTERM will kill any deamon that \nhasn't seen the proper handshake yet.\n\nOnce it's seen the proper handshake, the deamon will block SIGTERM. \nExactly so that if there is a SYN attack, people who use a non-git-aware \nSYN generator will be second-class citizens. So there's not a real \nchallenge-response thing, but at least it's set up so that real git \nclients (or something that looks like one) can be recognized, and get \npreferred treatment over people who just open a connection.\n\nOf course, this part doesn't work with the kernel.org setup, since that \nuses inetd, but we could easily add a timeout too, and do the same exact \nthing for SIGALRM (and just do an \"alarm(timeout)\" at the head of \n\"execute()\" before we start really trying to read from the socket).\n\nIn other words, git-daemon _already_ has support to help fight SYN \nattacks, although it currently only works when stand-alone. It could be \nextended to work with inetd, though.\n\nNOTE! Right now, a git-aware SYN-flooder could send a SYN + \n\"git-upload-pack /valid/directory\" thing in the proper packed-line format, \nand _then_ just go away. But once you're talking to a git-aware \nSYN-flooder, I don't think a challenge-response makes it any better, since \na git-aware SYN-flooder would just be written to give the right response.\n\nSo unless you actually have _passwords_, and make the response something \nthat the other end has to figure out some other way, I don't see what else \nwe could do..\n\n\t\t\tLinus\n"},{"id":"10306","messageId":"7voe5l2mvu.fsf@assigned-by-dhcp.cox.net","threadId":"2155","inReplyTo":"Pine.LNX.4.64.0510191410570.3369@g5.osdl.org","subject":"Re: The git protocol and DoS","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-19T21:54:45Z","receivedAt":"2005-10-19T21:54:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> But once you're talking to a git-aware \n> SYN-flooder, I don't think a challenge-response makes it any better, since \n> a git-aware SYN-flooder would just be written to give the right response.\n\nI think Peter's point is that the one that can give the right\nresponse needs to read from the server to compute it, and at\nthat point it is not a \"SYN-flooder\" anymore.\n"},{"id":"10307","messageId":"4356C1BD.5060806@zytor.com","threadId":"2155","inReplyTo":"7vek6h43oj.fsf@assigned-by-dhcp.cox.net","subject":"Re: The git protocol and DoS","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-19T21:59:25Z","receivedAt":"2005-10-19T21:59:25Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \"H. Peter Anvin\" writes:\n> \n>>You mean an option on the *server* to skip the cookie exchange? If so, \n>>how would you expect the client to handle it?\n> \n> No, what I was thinking was to tell the client \"you will be\n> talking to an old server, so do not try to read that cookie and\n> get stuck\".\n> \n\nOh, right.\n\n\t-hpa\n"},{"id":"10308","messageId":"4356C22F.2040304@zytor.com","threadId":"2155","inReplyTo":"7voe5l2mvu.fsf@assigned-by-dhcp.cox.net","subject":"Re: The git protocol and DoS","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-19T22:01:19Z","receivedAt":"2005-10-19T22:01:19Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> Linus Torvalds writes:\n> \n>>But once you're talking to a git-aware \n>>SYN-flooder, I don't think a challenge-response makes it any better, since \n>>a git-aware SYN-flooder would just be written to give the right response.\n> \n> I think Peter's point is that the one that can give the right\n> response needs to read from the server to compute it, and at\n> that point it is not a \"SYN-flooder\" anymore.\n> \n\nRight. It has been shown that requiring some effort on the part of the \nclient before the server spends work on it can greatly reduce the \ncapabilities of a limited-resource client to execute a DoS.\n\n\t-hpa\n"},{"id":"10311","messageId":"20051019222044.GP30889@pasky.or.cz","threadId":"2155","inReplyTo":"4356A5C5.5080905@zytor.com","subject":"Re: The git protocol and DoS","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-10-19T22:20:44Z","receivedAt":"2005-10-19T22:20:44Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Oct 19, 2005 at 10:00:05PM CEST, I got a letter\nwhere \"H. Peter Anvin\" told me that...\n> One way to do this would be to start the transaction by having the \n> server transmit a cookie to the client, and to require the client to \n> send a SHA1 of the (cookie + request) together with the request. This \n> would be done with a fairly short timeout.\n\n If (well, it sounds like a good idea, so rather \"when\") you do this,\nit would be a good idea to do in a way that makes it easy to later add\nsupport for some kind of authentication (really, not everyone wants to\ngive away ssh accounts). Let's say it works like:\n\n[client]\tgit-upload-pack \n[server]\tchallenge somethingnonsensical\n[client]\tchallenge-response :sha1(somethingnonsensical)\n[server]\tAll right, the pack goes like this...\n\n Suddenly you have support for hopefully secure authentication, and at\nthe same time you have the cookie implemented in backwards-compatible\nfashion (in the sense that new client will be able to talk to old\nserver) - just assume the username and password empty. This might be\neven hardcoded for now, just leave a room for its addition (in an\nelegant and compatible way) in the protocol, please.\n\n Thanks,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"10314","messageId":"12c511ca0510191539w3dd76f89ra5fe48e1d84750d6@mail.gmail.com","threadId":"2155","inReplyTo":"20051019222044.GP30889@pasky.or.cz","subject":"Re: The git protocol and DoS","fromName":"Tony Luck","fromEmail":"tony.luck@gmail.com","sentAt":"2005-10-19T22:39:55Z","receivedAt":"2005-10-19T22:39:55Z","isPatch":false,"sender":{"key":"tony.luck@gmail.com","avatar":null},"body":"On 10/19/05, Petr Baudis wrote:\n> [client] git-upload-pack \n> [server] challenge somethingnonsensical\n> [client] challenge-response :sha1(somethingnonsensical)\n> [server] All right, the pack goes like this...\n\nI think this requires that the server store the cleartext version of\nthe password so\nthat it can validate sha1(somethingnonsensical) ... which is generally\nthought to be a bad idea.\n\n-Tony\n"},{"id":"10320","messageId":"20051020002040.GA30232@old.davidb.org","threadId":"2155","inReplyTo":"20051019222044.GP30889@pasky.or.cz","subject":"Re: The git protocol and DoS","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2005-10-20T00:20:41Z","receivedAt":"2005-10-20T00:20:41Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Thu, Oct 20, 2005 at 12:20:44AM +0200, Petr Baudis wrote:\n\n> If (well, it sounds like a good idea, so rather \"when\") you do this,\n> it would be a good idea to do in a way that makes it easy to later add\n> support for some kind of authentication (really, not everyone wants to\n> give away ssh accounts). Let's say it works like:\n> \n> [client]\tgit-upload-pack \n> [server]\tchallenge somethingnonsensical\n> [client]\tchallenge-response :sha1(somethingnonsensical)\n> [server]\tAll right, the pack goes like this...\n> \n> Suddenly you have support for hopefully secure authentication, and at\n> the same time you have the cookie implemented in backwards-compatible\n> fashion (in the sense that new client will be able to talk to old\n> server) - just assume the username and password empty. This might be\n> even hardcoded for now, just leave a room for its addition (in an\n> elegant and compatible way) in the protocol, please.\n\nThis kind of password authentication has several problems that make it\nfairly unpractical. It is prone to easy dictionary attacks for one thing.\nIt also for a spoofed server to do replays, and the likes. It also\nrequires the server to store plaintext passwords.\n\nThere are other, much better, authentication algorithms, but short of doing\nsignatures, none are really much more secure. The closest you'll get to\nsecure remote passwords is SRP , which is quite\ngood, and doesn't even require plaintext passwords to be stored. It might\njust be easier at that point to use signatures, though.\n\nDave\n"},{"id":"10345","messageId":"4357526D.2000807@op5.se","threadId":"2155","inReplyTo":"20051019222044.GP30889@pasky.or.cz","subject":"Re: The git protocol and DoS","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-10-20T08:16:45Z","receivedAt":"2005-10-20T08:16:45Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Petr Baudis wrote:\n> Dear diary, on Wed, Oct 19, 2005 at 10:00:05PM CEST, I got a letter\n> where \"H. Peter Anvin\" told me that...\n> \n>>One way to do this would be to start the transaction by having the \n>>server transmit a cookie to the client, and to require the client to \n>>send a SHA1 of the (cookie + request) together with the request. This \n>>would be done with a fairly short timeout.\n> \n> \n> If (well, it sounds like a good idea, so rather \"when\") you do this,\n> it would be a good idea to do in a way that makes it easy to later add\n> support for some kind of authentication (really, not everyone wants to\n> give away ssh accounts). Let's say it works like:\n> \n> [client]\tgit-upload-pack \n> [server]\tchallenge somethingnonsensical\n> [client]\tchallenge-response :sha1(somethingnonsensical)\n> [server]\tAll right, the pack goes like this...\n> \n> Suddenly you have support for hopefully secure authentication, and at\n> the same time you have the cookie implemented in backwards-compatible\n> fashion (in the sense that new client will be able to talk to old\n> server) - just assume the username and password empty. This might be\n> even hardcoded for now, just leave a room for its addition (in an\n> elegant and compatible way) in the protocol, please.\n> \n\nI think git-daemon would be better off without this, since\n* A project rarely grants write access to the central repo (or whatever \ngit has, I'm still fairly new to it) without being willing to give out \nssh access, often limited by the ssh command whitelist.\n* It's hard to do right.\n* Passwords are never as secure or as convenient as public key \nauthentication and there's no point in spending a lot of time \nre-inventing ssh.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"}]}