Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1
On 2014-04-25 03:37, Simon Oosthoek wrote: (though tbh, I think you'd have to be in an automated situation to check out a branch that is basically a command to hack your system, a human would probably figure it too cumbersome, or too fishy) You can get in trouble by cloning a malicious repository and cding to the resulting directory. See: https://github.com/richardhansen/clonepwn for a (benign) demonstration. (Note the name of the default branch in that repository -- it's not master.) + # not needed anymore; keep user's + # environment clean + unset __git_ps1_upstream_name We already have a lot of stuff in the user's environment beginning with __git, so I don't think the unset is necessary. If people rely on the string being set in their scripts, it can be bad to remove it. But if it's new in this patch, The variable is new. I don't see the need to keep it. Cruft is bad IMO. Agreed, although I am willing to remove those three lines if that is the collective preference. -Richard -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1
Hi,
On Apr 22, 2014 2:53 AM, Junio C Hamano gits...@pobox.com wrote:
Richard Hansen rhan...@bbn.com writes:
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)'.
Signed-off-by: Richard Hansen rhan...@bbn.com
I'd like to see this patch eyeballed by those who have been involved
in the script (shortlog and blame tells me they are SZEDER and
Simon, CC'ed), so that we can hopefully merge it by the time -rc1 is
tagged.
I think this is a sensible thing to do. However, for now I can only check the
patch on my phone, hence I can't say any more (e.g. acked or reviewed by) than
that, unfortunately.
+ # not needed anymore; keep user's
+ # environment clean
+ unset __git_ps1_upstream_name
+ fi
We already have a lot of stuff in the user's environment beginning with __git,
so I don't think the unset is necessary.
Best,
Gábor
N�r��yb�X��ǧv�^�){.n�+ا���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1
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
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1
Michael Haggerty mhag...@alum.mit.edu writes:
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 think we forbid these at the Porcelain level (git branch, git
checkout -b and git tag should not let you create -aBranch),
while leaving the plumbing lax to allow people experimenting with
their repositories.
It may be sensible to discuss and agree on what exactly should be
forbidden (we saw leading dash, semicolon and dollar anywhere
so far in the discussion) and plan for transition to forbid them
everywhere in a next big version bump (it is too late for 2.0).
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1
On 2014-04-22 13:38, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
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 think we forbid these at the Porcelain level (git branch, git
checkout -b and git tag should not let you create -aBranch),
while leaving the plumbing lax to allow people experimenting with
their repositories.
It may be sensible to discuss and agree on what exactly should be
forbidden (we saw leading dash, semicolon and dollar anywhere
so far in the discussion)
Also backquote anywhere.
and plan for transition to forbid them
everywhere in a next big version bump (it is too late for 2.0).
Would it be acceptable to have a config option to forbid these in a
non-major version bump? Does parsing config files add too much overhead
for this to be feasible?
If it's OK to have a config option, then here's one possible transition
path (probably flawed, but my intent is to bootstrap discussion):
1. Add an option to forbid dangerous characters. The option defaults
to disabled for compatibility. If the option is unset, print a
warning upon encountering a ref name that would be forbidden.
2. Later, flip the default to enabled.
3. Later, in the weeks/months leading up to the next major version
release, print the warning even if the config option is set to
disabled.
Thanks,
Richard
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1
Richard Hansen rhan...@bbn.com writes: and plan for transition to forbid them everywhere in a next big version bump (it is too late for 2.0). Would it be acceptable to have a config option to forbid these in a non-major version bump? Of course ;-) Because we try very hard to avoid a flag day change, any plan for transition inevitably has to include what we need to do _before_ the big version bump. If it's OK to have a config option, then here's one possible transition path (probably flawed, but my intent is to bootstrap discussion): 1. Add an option to forbid dangerous characters. The option defaults to disabled for compatibility. If the option is unset, print a warning upon encountering a ref name that would be forbidden. 2. Later, flip the default to enabled. 3. Later, in the weeks/months leading up to the next major version release, print the warning even if the config option is set to disabled. Sounds fairly conservative and nice. We may want to treat creating a new such ref and using an existing such ref differently, though, and that might give us a better/smoother transition (as you are, I am just thinking aloud). For example, it might be sufficient to do these two things: (1) upon an attempt to use an existing such ref, warn and encourage renaming of the ref. (2) upon an attempt to create a new one, error it out. in the first step, and in either case, tell the user about the loosening variable. Going that route may shorten the time until the initial safety. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1
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)'.
Signed-off-by: Richard Hansen rhan...@bbn.com
---
To see the vulnerability in action, follow the instructions at:
https://github.com/richardhansen/clonepwn
contrib/completion/git-prompt.sh | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 7b732d2..bd7ff29 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -207,7 +207,18 @@ __git_ps1_show_upstream ()
p= u+${count#* }-${count% *} ;;
esac
if [[ -n $count -n $name ]]; then
- p=$p $(git rev-parse --abbrev-ref $upstream
2/dev/null)
+ __git_ps1_upstream_name=$(git rev-parse \
+ --abbrev-ref $upstream 2/dev/null)
+ if [ $pcmode = yes ]; then
+ # see the comments around the
+ # __git_ps1_branch_name variable below
+ p=$p \${__git_ps1_upstream_name}
+ else
+ p=$p ${__git_ps1_upstream_name}
+ # not needed anymore; keep user's
+ # environment clean
+ unset __git_ps1_upstream_name
+ fi
fi
fi
@@ -438,8 +449,27 @@ __git_ps1 ()
__git_ps1_colorize_gitstring
fi
+ b=${b##refs/heads/}
+ if [ $pcmode = yes ]; then
+ # In pcmode (and only pcmode) the contents of
+ # $gitstring are subject to expansion by the shell.
+ # Avoid putting the raw ref name in the prompt to
+ # protect the user from arbitrary code execution via
+ # specially crafted ref names (e.g., a ref named
+ # '$(IFS=_;cmd=sudo_rm_-rf_/;$cmd)' would execute
+ # 'sudo rm -rf /' when the prompt is drawn). Instead,
+ # put the ref name in a new global variable (in the
+ # __git_ps1_* namespace to avoid colliding with the
+ # user's environment) and reference that variable from
+ # PS1.
+ __git_ps1_branch_name=$b
+ # note that the $ is escaped -- the variable will be
+ # expanded later (when it's time to draw the prompt)
+ b=\${__git_ps1_branch_name}
+ fi
+
local f=$w$i$s$u
- local gitstring=$c${b##refs/heads/}${f:+$z$f}$r$p
+ local gitstring=$c$b${f:+$z$f}$r$p
if [ $pcmode = yes ]; then
if [ ${__git_printf_supports_v-} != yes ]; then
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1
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. 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. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1
Richard Hansen rhan...@bbn.com writes:
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)'.
Signed-off-by: Richard Hansen rhan...@bbn.com
I'd like to see this patch eyeballed by those who have been involved
in the script (shortlog and blame tells me they are SZEDER and
Simon, CC'ed), so that we can hopefully merge it by the time -rc1 is
tagged.
Will queue so that I won't lose it in the meantime.
Thanks.
contrib/completion/git-prompt.sh | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-prompt.sh
b/contrib/completion/git-prompt.sh
index 7b732d2..bd7ff29 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -207,7 +207,18 @@ __git_ps1_show_upstream ()
p= u+${count#* }-${count% *} ;;
esac
if [[ -n $count -n $name ]]; then
- p=$p $(git rev-parse --abbrev-ref $upstream
2/dev/null)
+ __git_ps1_upstream_name=$(git rev-parse \
+ --abbrev-ref $upstream 2/dev/null)
+ if [ $pcmode = yes ]; then
+ # see the comments around the
+ # __git_ps1_branch_name variable below
+ p=$p \${__git_ps1_upstream_name}
+ else
+ p=$p ${__git_ps1_upstream_name}
+ # not needed anymore; keep user's
+ # environment clean
+ unset __git_ps1_upstream_name
+ fi
fi
fi
@@ -438,8 +449,27 @@ __git_ps1 ()
__git_ps1_colorize_gitstring
fi
+ b=${b##refs/heads/}
+ if [ $pcmode = yes ]; then
+ # In pcmode (and only pcmode) the contents of
+ # $gitstring are subject to expansion by the shell.
+ # Avoid putting the raw ref name in the prompt to
+ # protect the user from arbitrary code execution via
+ # specially crafted ref names (e.g., a ref named
+ # '$(IFS=_;cmd=sudo_rm_-rf_/;$cmd)' would execute
+ # 'sudo rm -rf /' when the prompt is drawn). Instead,
+ # put the ref name in a new global variable (in the
+ # __git_ps1_* namespace to avoid colliding with the
+ # user's environment) and reference that variable from
+ # PS1.
+ __git_ps1_branch_name=$b
+ # note that the $ is escaped -- the variable will be
+ # expanded later (when it's time to draw the prompt)
+ b=\${__git_ps1_branch_name}
+ fi
+
local f=$w$i$s$u
- local gitstring=$c${b##refs/heads/}${f:+$z$f}$r$p
+ local gitstring=$c$b${f:+$z$f}$r$p
if [ $pcmode = yes ]; then
if [ ${__git_printf_supports_v-} != yes ]; then
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1
Junio C Hamano gits...@pobox.com writes:
Richard Hansen rhan...@bbn.com writes:
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)'.
Signed-off-by: Richard Hansen rhan...@bbn.com
I'd like to see this patch eyeballed by those who have been involved
in the script (shortlog and blame tells me they are SZEDER and
Simon, CC'ed), so that we can hopefully merge it by the time -rc1 is
tagged.
Will queue so that I won't lose it in the meantime.
Thanks.
Sadly, this does not seem to pass t9903.41 for me.
$ bash t9903-*.sh -i -v
ends with this:
--- expected2014-04-21 22:31:46.0 +
+++ .../t/trash directory.t9903-bash-prompt/actual ...
@@ -1 +1 @@
-BEFORE: (master):AFTER
\ No newline at end of file
+BEFORE: (${__git_ps1_branch_name}):AFTER
\ No newline at end of file
not ok 41 - prompt - pc mode
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1
On 2014-04-21 18:33, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: Richard Hansen rhan...@bbn.com writes: 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)'. Signed-off-by: Richard Hansen rhan...@bbn.com I'd like to see this patch eyeballed by those who have been involved in the script (shortlog and blame tells me they are SZEDER and Simon, CC'ed), so that we can hopefully merge it by the time -rc1 is tagged. Will queue so that I won't lose it in the meantime. Thanks. Sadly, this does not seem to pass t9903.41 for me. $ bash t9903-*.sh -i -v Oops! Because git-prompt.sh is in contrib I didn't realize there was a test for it. The test will have to change. I'll think about the best way to adjust the test and send a reroll. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
