Re: The git protocol and DoS

On Wed, 19 Oct 2005, H. Peter Anvin wrote:

Hey guys, I actually planned for the protocol to be extensible.

The client always starts out by sending the "command" first, and if you want to add a challenge-response thing, I really think you should make it a nice compatible upgrade (and then later on, you can have a server option that says "if the client doesn't do the challenge-response version, I won't talk to him").

Basically, right now the client sends a

	"git-upload-pack /absolute/pathname/to/repo"

over the protocol, and the whole point of this was that (a) it's extensible and (b) the server knows what to expect, and can close the socket if it doesn't get a valid packet.

So if you add some extra challenge-response thing, please just do so by changing the string. Teach the server to also accept

	"git-upload-pack --challenge /absolute/pathname/to/repo"

for example. Then later, add a "secure server" mode that refuses to do the old non-challenge response.

HOWEVER. The server _already_ has some of this logic: if you start it outside of inetd, it will start killing its own children when there are too many of them, but it will start by sending them a SIGTERM. And the git-daemon code is set up so that a SIGTERM will kill any deamon that hasn't seen the proper handshake yet.

Once it's seen the proper handshake, the deamon will block SIGTERM. Exactly so that if there is a SYN attack, people who use a non-git-aware SYN generator will be second-class citizens. So there's not a real challenge-response thing, but at least it's set up so that real git clients (or something that looks like one) can be recognized, and get preferred treatment over people who just open a connection.

Of course, this part doesn't work with the kernel.org setup, since that uses inetd, but we could easily add a timeout too, and do the same exact thing for SIGALRM (and just do an "alarm(timeout)" at the head of "execute()" before we start really trying to read from the socket).

In other words, git-daemon _already_ has support to help fight SYN attacks, although it currently only works when stand-alone. It could be extended to work with inetd, though.

NOTE! Right now, a git-aware SYN-flooder could send a SYN + "git-upload-pack /valid/directory" thing in the proper packed-line format, and _then_ just go away. But once you're talking to a git-aware SYN-flooder, I don't think a challenge-response makes it any better, since a git-aware SYN-flooder would just be written to give the right response.

So unless you actually have _passwords_, and make the response something that the other end has to figure out some other way, I don't see what else we could do..

			Linus