Re: [RFC] Malicously tampering git metadata?

[Stefan Beller <sbeller@google.com>]

On Tue, Jan 12, 2016 at 10:21 AM, Santiago Torres <santiago@nyu.edu> wrote:
> Hello Everyone,
>
> Thanks for the feedback regarding our attack scenario; it certainly shed some
> light in what is the current state of git's metadata protection. We were
> pleasantly surprised that attacks of this nature were considered, yet we think
> we can improve on the current mechanisms.
>
> We have been designing an extension that addresses this attack scenario (and
> other similar attacks). Although originally it is not based on push
> certificates, we feel that it works similar to them. The principal advantages
> over push certificates are:
>
> 1) It doesn't require (although it could support it) a side channel. We store similar
>     information about branch status (push status) on the repository itself.
>
> 2) It is backwards compatible, as it doesn't modify the existing metadata
>     format.
>
> 3) Following Ted's email, it could be easily integrated in any git workflow.
>     Although some workflows might be benefitted more than others, it doesn't
>     get in the way of any existing workflow that we know of.
>
> 4) It covers a broader attack suurface (e.g., our malicious-merge scenario).
>
> To keep things simple (we can elaborate in further emails), our solution
> basically works by keeping track of pushes by developers in an append only
> file, so that, everytime a branch is pushed, the deloper signs his version of
> the log and his "push entry" (similar to a push certificate). Right now, we
> push this log to a separate branch called BSL (for Branch State Log), but
> ideallly this could be part of the git metadata.

Recently in another context (an alternative refs backend) there was a proposal
by Shawn to keep the .git directory versioned by git itself, i.e.
having only loose refs in
.git/refs and then there is a repository tracking .git/refs as a
directory structure.

Using that idea of a refs back end, combined with signed tags in the
refs repository
would give you signed version of the log of possible push entries.

>
> Upon pulling/fetching, this push certificate chain (BSL) is also fetched
> and used to verify whether all branches are pointing to a sensible
> location (i.e., the location reported by the last user who
> pushed/merged).This ensures that a malicious server can't change the
> location to which branches point to.

This is what push certs ought to solve already?
AFAIU the main issue with untrustworthy servers is holding back the latest push.
As Ted said, usually there is problem in the code and then the fix is pushed,
but the malicious server would not advertise the update, but deliver the old
unfixed version.

This attack cannot be mitigated by having either a side channel (email
announcements)
or time outs (state is only good if push cert is newer than <amount of
time>, but this may
require empty pushes)


>
> Furthermore, upon fetching, users with write access also push an entry
> indicating that they fetched the BSL. This avoids cases in which a malicious
> attacker keeps older versions of the BSL and withhold changes to other users.

This would make it a "be malicious to all or none" thing? So the
attacker cannot attack
a single target IIUC.

I have a bad feeling about repository modifications upon fetching as
software distribution
is a highly asymmetric workflow (number of fetches is many orders of
magnitudes larger than
pushes), which may not scale well? (How would you serialize parallel
fetches into the BSL?)

Thanks,
Stefan