Re: [RFC] Malicously tampering git metadata?

From: Theodore Ts'o <tytso@mit.edu>
Date: Dec 20, 2015, 01:28 UTC
Message-ID: <20151220012835.GA3013@thunk.org>
In-Reply-To: <20151219173018.GA1178@LykOS>

On Sat, Dec 19, 2015 at 12:30:18PM -0500, Santiago Torres wrote:

Show 8 quoted lines

> > Now, the crazy behavior where github users randomly and promiscuously
> > do pushes and pull without doing any kind of verification may very
> > well be dangerous. 
> 
> Yes, we were mostly familiar with this workflow before starting this
> research. I can see how the "github generation" is open to many attacks
> of this nature. Would git be interested in integrating a defense that
> covers users of this nature (which seems to be a growing userbase)?

One of the interesting challenges is that git is a pretty low-level tool, and so people have built all sorts of different workflows on top of it.

For example, at $WORK, we use gerrit, which is a code review tool, so all git commits that are to be merged into the "upstream" repository 0gets pushed to a gerrit server, where it goes through a code review process where a second engineer can review the code, request changes, make comments, or ask questions, and where the git commits can go through multiple rounds of review / revision before they are finally accepted (at least one reviewer must give a +2 review, and there must be no -2 reviews; and there can be automated tools that do build or regression tests that can give automated -1 or -2 reviews) --- and where all of the information collected during the code review process is saved as part of the audit trail for a Sarbanes-Oxley (SOX) compliance regime.

Other people use github-style workflows, and others use signed tags with e-mail code reviews, etc. And I'm sure there must be many others.

So the challenge is that in order to accomodate many possible workflows, some of which use third-party tools, changes to make git more secure for one workflow must not get in the way of these other workflows --- which means that enforcement of new controls for the "github generation" probably will have to be optional. But then people belonging to the "github generation" can also easily turn off these features. And as the NSA learned the hard way in Vietnam, if the tools cause any inconenience, or has the perception of constraining legitmate users, security features can have a way of getting turned off.[1]

[1] A History of US Communications Security, The David G. Boak lectures, Volume II, "Nestor in Vietname". pg 43-44. (A declassified version can be found at: http://www.governmentattic.org/18docs/Hist_US_COMSEC_Boak_NSA_1973u.pdf)

Show 9 quoted lines

> > But so is someone who saves a 80 patch series from
> > their inbox, and without reading or verifying all of the patches
> > applies them blindly to their tree using "git am" --- or if they were
> > using cvs or svn, bulk applied the patches without doing any
> > verification....
> 
> Just out of curiosity, are there known cases of projects in which this
> has happened (I've noticed that both Git and Linux are quite stringent
> in their review/merge process so this wouldn't be the case).

I can't point at specific instances, but given that in the "github generation", people are fine with blindly pulling someone else's Docker images and running it on their production servers or workstations, and where software installation gets done with "wget http://example.org | bash" or the equivalent, that it's probably more often than we might be comfortable.

I also suspect that a bad guy would probably find inserting a man-in-the-middle server into one of these installation flows is probably a much more practical attack in terms of real world considerations. :-)

Cheers,

						- Ted