Re: [RFC] Malicously tampering git metadata?

From: Santiago Torres <santiago@nyu.edu>
Date: Dec 19, 2015, 17:30 UTC
Message-ID: <20151219173018.GA1178@LykOS>
In-Reply-To: <20151218231032.GA16904@thunk.org>

Show 29 quoted lines

> I assume you are assuming here that the "push to upstream" doesn't
> involve some kind of human verification?  If someone tried pushing
> something like this to Linus, he would be checking the git diff stats
> and git commit structure for things that might look like "developer
> negligence".  He's been known to complain to subsystem developers in
> his own inimitable when the git commit structure looks suspicious, so
> I'm pretty sure he would notice this.
> 
> For example, in my use case, I'm authorative over changes in fs/ext4.
> So when I pull from Linus's repo, I examine (using "gitk fs/ext4") all
> commits coming from upstream that modify fs/ext4.  So if someone tries
> introducing a change in fs/ext4 coming from "upstream", I will notice.
> Then when I request a pull request from Linus, the git pull request
> describes what commits are new in my tree that are not in his, and
> shows the diffstats from upstream.  When Linus verifies my pull, there
> are multiple opportunities where he will notice funny business:
> 
> a) He would notice that my origin commit is something that is not in
> his upstream tree.
> 
> b) His diffstat is different from my diffstat (since thanks to the
> man-in-the middle, the conception of what commits are new in the git
> pull request will be different from his).
> 
> c) His diffstat will show that files outside of fs/ext4 have been
> modified, which is a red flag that will merit more close examination.
> (And if the attacker had tried to introduce a change in fs/ext4, I
> would have noticed when I pulled from the man-in-the-middle git
> repo.)

Yes, we've been considering that these kind of attacks wouldn't be too effective against, let's say, dictator-lieutenant workflows.

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

Show 5 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).

> 
> Cheers,

Thanks for the insight! -Santiago.