Re: [OT] USENIX paper on Git
- From
Santiago Torres <santiago@nyu.edu>
- Date
- Aug 3, 2016, 18:02 UTC
- Message-ID
- <20160803180214.rxz455nlcm5hqn37@LykOS.localdomain>
- In-Reply-To
- <CAGZ79kY8knsXEVqfbdoHGdEzOfygVoaZi43jy_yERnx=enuRcA@mail.gmail.com>
On Wed, Aug 03, 2016 at 10:35:39AM -0700, Stefan Beller wrote:
Show 39 quoted lines
> 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.