git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Hansen <rhansen@bbn.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, sitaramc@gmail.com
Subject: Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1
Date: Mon, 21 Apr 2014 17:07:18 -0400	[thread overview]
Message-ID: <53558886.5080102@bbn.com> (raw)
In-Reply-To: <20140421202454.GA6062@sigill.intra.peff.net>

On 2014-04-21 16:24, Jeff King wrote:
> On Mon, Apr 21, 2014 at 03:07:28PM -0400, Richard Hansen wrote:
> 
>> Both bash and zsh subject the value of PS1 to parameter expansion,
>> command substitution, and arithmetic expansion.  Rather than include
>> the raw, unescaped branch name in PS1 when running in two- or
>> three-argument mode, construct PS1 to reference a variable that holds
>> the branch name.  Because the shells do not recursively expand, this
>> avoids arbitrary code execution by specially-crafted branch names such
>> as '$(IFS=_;cmd=sudo_rm_-rf_/;$cmd)'.
> 
> Cute. We already disallow quite a few characters in refnames (including
> space, as you probably discovered), and generally enforce that during
> ref transfer. I wonder if we should tighten that more as a precuation.
> It would be backwards-incompatible, but I wonder if things like "$" and
> ";" in refnames are actually useful to people.

That's a tough call.  I imagine those that legitimately use '$', ';', or
'`' would be annoyed but generally accepting given the security benefit.

I wonder how many repos at sites like GitHub use unusual punctuation in
ref names.

Perhaps the additional character restrictions could be controlled via a
config option.  It would default to the more secure mode but
developers/repo admins could relax it where required.

If imposing additional character restrictions is unpalatable, hooks
could be used to reject funny branch names in shared repos.  But this
would require administrator action -- it's not as secure by default.

> 
> Did you look into similar exploits with completion? That's probably
> slightly less dire (this one hits you as soon as you "cd" into a
> malicious clone, whereas completion problems require you to actually hit
> <tab>). I'm fairly sure that we miss some quoting on pathnames, for
> example. That can lead to bogus completion, but I'm not sure offhand if
> it can lead to execution.

I have not looked at the completion code.

-Richard

  reply	other threads:[~2014-04-21 21:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-21 19:07 [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1 Richard Hansen
2014-04-21 20:24 ` Jeff King
2014-04-21 21:07   ` Richard Hansen [this message]
2014-04-22  8:38   ` Michael Haggerty
2014-04-22 17:38     ` Junio C Hamano
2014-04-22 18:38       ` Richard Hansen
2014-04-22 19:47         ` Junio C Hamano
2014-04-21 22:23 ` Junio C Hamano
2014-04-21 22:33   ` Junio C Hamano
2014-04-21 22:58     ` Richard Hansen
2014-04-21 23:53       ` [SECURITY PATCH v2] " Richard Hansen
  -- strict thread matches above, loose matches on Subject: below --
2014-04-24 18:40 [SECURITY PATCH] " Gábor Szeder
2014-04-25  7:37 ` Simon Oosthoek
2014-04-25 16:39   ` Richard Hansen

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=53558886.5080102@bbn.com \
    --to=rhansen@bbn.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=sitaramc@gmail.com \
    /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).