On Thu, Dec 01, 2011 at 06:59:04PM -0800, Bill Zaumen wrote: > > What about the server being more clever about hiding the replacement > > object? E.g., instead of just breaking into kernel.org and inserting a > > replacement object, the attacker runs a malicious git-daemon that > > returns the bogus object to cloners, but the real object to fetchers. > > That's really a server-security issue, not a git one. Perhaps > repositories should be configured so that all the executables are on > read-only partitions. It's an important question in general of > course, but it is probably useful to distinguish attacks that put > bad data on a server from ones that install new software. I don't agree here. You have to assume that the attacker will ignore attacks you have blocked, but continue with ones you haven't (just to counter your example, why not replace the running git-daemon in-memory?). You can target the narrow window of attacks that compromise the on-disk repository without being able to execute arbitrary code. But I don't see a point. After the kernel.org hack, yes, people are interested in hardening kernel.org. But they are much more interested in cryptographic sources of authority that let us not have to trust kernel.org at all. Having some weird half-way trust just complicates things. > > But we can already do that. Assume you have an existing repo "foo". To > > verify the copy at git://example.com/foo.git, do a fresh clone to > > "bar", and then compare the objects in "foo" to "bar", either byte-wise > > or by digest. > > Of course, but that is an expensive operation - in the case of Git > transferring some 50 MBytes of data per repository. A command to > fetch the SHA-1 ID and a CRC or message digest for each object would > not only run faster, but should put a much lower load on the server. Yes, it is more expensive. But again, my threat model is that the server is not trusted to serve data accurately or consistently. So you can't come to the server and say "Hey, I'm doing a security verification. Can you send me the CRCs?" You _have_ to present yourself as one of the victims to be infected by the bad object, or a smart attacker will send you the unmodified data. > Getting back to the birthday attack question (this is an area where > your comments were very useful for me), there's a case I didn't > consider. > [elaborate birthday attack scenario] >From my quick reading of your scenario, yes, that is a possible attack. To me, though, it just highlights the need for either a non-colliding algorithm, or for better trust verification about the authors of objects (i.e., cryptographically strong trust). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html