All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Jordi Vilar <git.kernel.org@jordi.vilar.cat>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org
Subject: Re: proposal for additional search path in config
Date: Wed, 2 Jun 2021 22:45:16 -0400	[thread overview]
Message-ID: <YLhCPMMhD9F3qH/l@nand.local> (raw)
In-Reply-To: <CAE-zgtZroyEwG1k9y-XXAx2NKPF=Lav4YG+f7mF227FEeuxDVw@mail.gmail.com>

On Wed, Jun 02, 2021 at 07:36:31PM +0200, Jordi Vilar wrote:
> > I am really wary about the security implications of this. Most obviously
> > with the idea of allowing to _override_ commands. Take for example
> > `git-lfs`: the assumption is that it is safe for Git to call `git-lfs`
> > after the initial check-out phase, but with this feature, it would be
> > possible for Git to clone a malicious repository and _immediately_
> > executing code it just cloned, _without_ giving the user a chance to even
> > inspect the code.
>
> You are again right. That's why I was suggesting the conservative
> approach of not prepending to the default search path, but appending
> to it, so there is no chance of overrinding existing tools.

To me, this does not appear to be a conservative approach as you
suggest.

The only difference between exporting PATH=$SEARCH_PATH:$PATH and
PATH=$PATH:$SEARCH_PATH is that the former allows overwriting the
results of looking up a binary in the path, but the latter lets you
resolve locations that $PATH alone would not find.

Suppose you maliciously included a git-lfs binary with your repository.
If you include that binary in your PATH ahead of the existing system
PATH, then you'll replace system git-lfs with your malicious one, which
I think you and I both agree is bad. But if you instead append the
malicious binary onto the right-hand side of your PATH, then you can't
overwrite a git-lfs already on the path, but you *can* trick a system
which doesn't have a version of git-lfs installed into thinking that one
exists.

So your exploit would just be limited to having someone clone your
repository who doesn't already have git-lfs installed into their path,
which I would argue is just as bad.

> Also, config is not versioned, so, right after cloning you wouldn't
> have this option enabled, so you are always safe after cloning [...]

I know that this has come up in some recent-ish discussions, and I have
not been convinced that this makes things any safer.

Thanks,
Taylor

      reply	other threads:[~2021-06-03  2:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210601113554.52585C06174A@lindbergh.monkeyblade.net>
2021-06-01 14:13 ` proposal for additional search path in config Jordi Vilar
2021-06-02 11:08   ` Johannes Schindelin
2021-06-02 17:36     ` Jordi Vilar
2021-06-03  2:45       ` Taylor Blau [this message]

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=YLhCPMMhD9F3qH/l@nand.local \
    --to=me@ttaylorr.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git.kernel.org@jordi.vilar.cat \
    --cc=git@vger.kernel.org \
    /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.