git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Santiago Torres <santiago@nyu.edu>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Git <git@vger.kernel.org>
Subject: Re: [RFC] Malicously tampering git metadata?
Date: Sat, 19 Dec 2015 12:30:18 -0500	[thread overview]
Message-ID: <20151219173018.GA1178@LykOS> (raw)
In-Reply-To: <20151218231032.GA16904@thunk.org>

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

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

  reply	other threads:[~2015-12-19 17:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-16  3:26 [RFC] Malicously tampering git metadata? Santiago Torres
2015-12-16  7:20 ` Stefan Beller
2015-12-18  1:06   ` Santiago Torres
2015-12-18  3:55     ` Jeff King
2015-12-18  4:02 ` Jeff King
2015-12-18 23:10 ` Theodore Ts'o
2015-12-19 17:30   ` Santiago Torres [this message]
2015-12-20  1:28     ` Theodore Ts'o
2016-01-12 18:21       ` Santiago Torres
2016-01-12 18:39         ` Stefan Beller
2016-01-14 17:16           ` Santiago Torres
2016-01-14 17:21             ` Stefan Beller
2016-01-22 18:00               ` Santiago Torres
2016-01-22 18:51                 ` Stefan Beller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151219173018.GA1178@LykOS \
    --to=santiago@nyu.edu \
    --cc=git@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).