Re: [OT] USENIX paper on Git

[Santiago Torres <santiago@nyu.edu>]

On Wed, Aug 03, 2016 at 10:35:39AM -0700, Stefan Beller wrote:
> On Wed, Aug 3, 2016 at 10:22 AM, Santiago Torres <santiago@nyu.edu> wrote:
> > On Wed, Aug 03, 2016 at 10:14:21AM -0700, Stefan Beller wrote:
> >> On Wed, Aug 3, 2016 at 8:25 AM, Santiago Torres <santiago@nyu.edu> wrote:
> >> >  > share things before they are published. Thankfully, this is OK in
> >> >> > USENIX's book. Here's the link:
> >> >> > http://i2.cdn.turner.com/cnnnext/dam/assets/160730192650-14new-week-in-politics-super-169.jpg
> >> >>
> >> >> While I had a good laugh, I am wondering whether this is the correct link?
> >> >
> >> > Oh my god, sorry, I meant to p, not to ctrl + v. My head is all over the
> >> > place as of late.
> >> >
> >> > Here's the correct link:
> >> >
> >> > http://isis.poly.edu/~jcappos/papers/torres_toto_usenixsec-2016.pdf
> >>
> >> In 4.1 you write:
> >> > Finally, Git submodules are also vulnerable, as they automatically track
> >> > a tag (or branch). If a build dependency is included in a project as a part
> >> > of the submodule, a package might be vulnerable via an underlying library.
> >>
> >> Submodules actually track commits, not tags or branches.
> >>
> >> This is confusing for some users, e.g. the user intended to track
> >> a library at version 1.1, but it tracks 1234abcd instead (which is what
> >> 1.1 points at).
> >
> > I'm assuming that git submodule update does update where the ref points
> > to, does it not?
> >
> > let me dig into this and try to take the necessary measures to correct
> > this
> >
> 
> "git submodule update" updates to the recorded sha1, which I assume is used
> by downstream users. If you are a maintainer and  you want to update the
> library used, you'd be interested in have "git submodule update
> --remote" to update
> the sha1 to the tracking branch, which then exposes the attacks presented.

I see, I just tried to reproduce this, and it seems that, with a simple
git clone --recursive [path], the submodule fetched does not update to
the "malicious ref." You're right.

So, in the end, git submodule update --remote also requires you to
create a new tree, right? Then this attack wouldn't be possible by just
fiddling with the refs if signing is in place, right?

Thanks for clarifying!
-Santiago.