Re: [RFC] Malicously tampering git metadata?

From: Santiago Torres <santiago@nyu.edu>
Date: Dec 18, 2015, 01:06 UTC
Message-ID: <20151218010635.GA16508@LykOS>
In-Reply-To: <CAGZ79kZNim0wp2fYKv2+6t+CaqqzjTThsm_KoAv1D_8OsD0qTQ@mail.gmail.com>

Hi Stefan, thanks for the insight.

Show 6 quoted lines

> This is what push certificates ought to solve.
> The server records all pushes and its signed certificates of pushes
> and by the difference of the
> refs (either in packed refs or as a loose ref) to the push certificate
> this tampering of
> the server can be detected.

Is there any specification about push certificates? I would like to read about them, but I don't seem to find documentation anywhere. Are they a part of git's specification?

Show 6 quoted lines

> 
> The push certs can however not be obtained via Git itself (they are
> just stored on the
> server for now for later inspection or similar), because to be really
> sure the client would
> need to learn about these push certificates out of band.

I was thinking that an in-band solution could be integrated as long as we assume a compromise would result in an complete (unreconcilable) fork attack; fork attacks aren't subtle and could be detected easily.

Show 7 quoted lines

> 
> The model there would be:
> * A vulnerable piece of software exists.
> * It get's fixed (and the fix is pushed with a signed push)
> * the MITM server doesn't show the fix (show the code from before fix) nor
>   the push certificate thereof
> * client still pulls vulnerable code

Yes, this is a possible attack vector. However, a server could also present a branch pointer as different (e.g., point an experimental branch to an unsigned v1.1 tag). This has other implications, as the code is pushed/pulled from upstream, it just goes somewhere different.

> 
> This model shows the distribution of push certs via the server itself may not be
> optimal.

Yes, it might not be optimal, but it could provide protection against the attack I just described, for more complex attacks might not be so subtle. Adding to this, developers likely coordinate their efforts through other means (sic), so the lack of a push certificate (withheld by a server) could raise some yellow flags.

We've made a proof of concept of such tool (in-bandh push certificates), and would like to share the basic design of it here. However, it follows our threat model: a compromised server that can't introduce malicious code (thanks to commit signing), but can modify branch pointers and other unsigned metadata to alter the repository's state.

> 
> Thanks for researching on Git,

Thanks for working in such a great tool :) -Santiago

> Stefan