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.
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.