Re: [RFC] Malicously tampering git metadata?

[Santiago Torres <santiago@nyu.edu>]

Hi Stefan, thanks for the insight. 

> 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?

> 
> 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.

> 
> 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