Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1

[Michael Haggerty <mhagger@alum.mit.edu>]

On 04/21/2014 10:24 PM, 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.

While we're at it, I think it would be prudent to ban '-' at the
beginning of reference name segments.  For example, reference names like

    refs/heads/--cmd=/sbin/halt
    refs/tags/--exec=forkbomb(){forkbomb|forkbomb&};forkbomb

are currently both legal, but I think they shouldn't be.  I wouldn't be
surprised if somebody could find a way to exploit
references-named-like-command-line-options.

At a minimum, it is very difficult to write scripts robust against such
names.  Some branch- and tag-oriented commands *require* short names and
don't allow the full reference name including refs/heads/ or refs/tags/
to be specified.  In such cases there is no systematic way to prevent
the names from being seen as command-line options.  And '--' by itself,
which many Unix commands use to separate options from arguments, has a
different meaning in Gitland.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/