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@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html