Re: Fetch/push lets a malicious server steal the targets of "have" lines

From: Matt McCutchen <matt@mattmccutchen.net>
Date: Nov 13, 2016, 02:44 UTC
Message-ID: <1479005056.3471.40.camel@mattmccutchen.net>
In-Reply-To: <xmqqpomiuu8q.fsf@gitster.mtv.corp.google.com>

On Sun, 2016-10-30 at 01:16 -0700, Junio C Hamano wrote:

Show 19 quoted lines

> Jon Loeliger <jdl@jdl.com> writes:
> 
> > 
> > Is there an existing protocol provision, or an extension to
> > the protocol that would allow a distrustful client to say to
> > the server, "Really, you have Y2?  Prove it."
> 
> There is not, but I do not think it would be an effective solution.
> 
> The issue is not the lack of protocol support, but how to determine
> that the other side needs such a proof for Y2 but not for other
> commits.  How does your side know what makes Y2 special and why does
> yout side think they should not have Y2?
> 
> Once you know how to determine Y2 is special, that knowledge can be
> used to abort the "push" before even starting.  When you are pushing
> back the 'master' and that 'master' reaches Y2, which must be kept
> secret, you shouldn't be pushing that 'master' to them, whether they
> claim to have Y2 or not.

FWIW, I can imagine a protocol that would prove possession for all
objects, which would completely fix the problem.  Each object would
have a "private" hash computed recursively over the object graph, just
like the ordinary object hash, but with a different seed.  The object
database would be extended to cache the private hash of every object.
 Then, during a fetch or push, when the two sides identify a matching
object, the side that would otherwise have had to send the object sends
the private hash.  Support for storing multiple hashes per object might
also be useful in some way for the migration to a stronger hash
function than SHA-1.

The next best solution, which doesn't require a protocol change but requires a little user intervention, is to have a configuration option per remote for a set of refs whose reachable objects are known to be safe to send to the server. This set presumably includes the remote's own remote-tracking refs. During fetch and push, the client looks for matches only among these "safe" objects, effectively emulating a repository containing only the safe objects. A fetch may update the remote-tracking refs to point to unsafe objects that were already in the local repository, effectively making them safe, but only after the server sends the content of these objects (and the client validates the hashes!).

Unfortunately, I'm not signing up to implement either solution. :(

Matt