# [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1 11 messages from 2014-04-21 to 2014-04-22. Participants: Richard Hansen, Jeff King, Junio C Hamano, Michael Haggerty. Thread: https://gitlist.dev/t/36464 ## Richard Hansen, 2014-04-21 19:07 Subject: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1 Message-ID: <1398107248-32140-1-git-send-email-rhansen@bbn.com> URL: https://gitlist.dev/e/1398107248-32140-1-git-send-email-rhansen%40bbn.com ``` 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 --- 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 ``` ## Jeff King, 2014-04-21 20:24 Subject: Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1 Message-ID: <20140421202454.GA6062@sigill.intra.peff.net> URL: https://gitlist.dev/e/20140421202454.GA6062%40sigill.intra.peff.net In-Reply-To: <1398107248-32140-1-git-send-email-rhansen@bbn.com> ``` 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 ). 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 ``` ## Richard Hansen, 2014-04-21 21:07 Subject: Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1 Message-ID: <53558886.5080102@bbn.com> URL: https://gitlist.dev/e/53558886.5080102%40bbn.com 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 > ). 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 ``` ## Junio C Hamano, 2014-04-21 22:23 Subject: Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1 Message-ID: URL: https://gitlist.dev/e/xmqq61m28gqj.fsf%40gitster.dls.corp.google.com In-Reply-To: <1398107248-32140-1-git-send-email-rhansen@bbn.com> ``` Richard Hansen 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 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 ``` ## Junio C Hamano, 2014-04-21 22:33 Subject: Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1 Message-ID: URL: https://gitlist.dev/e/xmqq1twq8g91.fsf%40gitster.dls.corp.google.com In-Reply-To: ``` Junio C Hamano writes: > Richard Hansen 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 > > 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: --- expected 2014-04-21 22:31:46.000000000 +0000 +++ .../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 ``` ## Richard Hansen, 2014-04-21 22:58 Subject: Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1 Message-ID: <5355A280.6020409@bbn.com> URL: https://gitlist.dev/e/5355A280.6020409%40bbn.com In-Reply-To: ``` On 2014-04-21 18:33, Junio C Hamano wrote: > Junio C Hamano writes: > >> Richard Hansen 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 >> >> 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 ``` ## Richard Hansen, 2014-04-21 23:53 Subject: [SECURITY PATCH v2] git-prompt.sh: don't put unsanitized branch names in $PS1 Message-ID: <1398124389-16627-1-git-send-email-rhansen@bbn.com> URL: https://gitlist.dev/e/1398124389-16627-1-git-send-email-rhansen%40bbn.com In-Reply-To: <5355A280.6020409@bbn.com> ``` 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 --- Changes since v1: update t/t9903-bash-prompt.sh contrib/completion/git-prompt.sh | 34 +++++++++++++++++++++++++++++-- t/t9903-bash-prompt.sh | 44 ++++++++++++++++++++-------------------- 2 files changed, 54 insertions(+), 24 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 diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh index 59f875e..6efd0d9 100755 --- a/t/t9903-bash-prompt.sh +++ b/t/t9903-bash-prompt.sh @@ -452,53 +452,53 @@ test_expect_success 'prompt - format string starting with dash' ' ' test_expect_success 'prompt - pc mode' ' - printf "BEFORE: (master):AFTER" >expected && + printf "BEFORE: (\${__git_ps1_branch_name}):AFTER\\nmaster" >expected && printf "" >expected_output && ( __git_ps1 "BEFORE:" ":AFTER" >"$actual" && test_cmp expected_output "$actual" && - printf "%s" "$PS1" >"$actual" + printf "%s\\n%s" "$PS1" "${__git_ps1_branch_name}" >"$actual" ) && test_cmp expected "$actual" ' test_expect_success 'prompt - bash color pc mode - branch name' ' - printf "BEFORE: (${c_green}master${c_clear}):AFTER" >expected && + printf "BEFORE: (${c_green}\${__git_ps1_branch_name}${c_clear}):AFTER\\nmaster" >expected && ( GIT_PS1_SHOWCOLORHINTS=y && __git_ps1 "BEFORE:" ":AFTER" >"$actual" - printf "%s" "$PS1" >"$actual" + printf "%s\\n%s" "$PS1" "${__git_ps1_branch_name}" >"$actual" ) && test_cmp expected "$actual" ' test_expect_success 'prompt - bash color pc mode - detached head' ' - printf "BEFORE: (${c_red}(%s...)${c_clear}):AFTER" $(git log -1 --format="%h" b1^) >expected && + printf "BEFORE: (${c_red}\${__git_ps1_branch_name}${c_clear}):AFTER\\n(%s...)" $(git log -1 --format="%h" b1^) >expected && git checkout b1^ && test_when_finished "git checkout master" && ( GIT_PS1_SHOWCOLORHINTS=y && __git_ps1 "BEFORE:" ":AFTER" && - printf "%s" "$PS1" >"$actual" + printf "%s\\n%s" "$PS1" "${__git_ps1_branch_name}" >"$actual" ) && test_cmp expected "$actual" ' test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty worktree' ' - printf "BEFORE: (${c_green}master${c_clear} ${c_red}*${c_clear}):AFTER" >expected && + printf "BEFORE: (${c_green}\${__git_ps1_branch_name}${c_clear} ${c_red}*${c_clear}):AFTER\\nmaster" >expected && echo "dirty" >file && test_when_finished "git reset --hard" && ( GIT_PS1_SHOWDIRTYSTATE=y && GIT_PS1_SHOWCOLORHINTS=y && __git_ps1 "BEFORE:" ":AFTER" && - printf "%s" "$PS1" >"$actual" + printf "%s\\n%s" "$PS1" "${__git_ps1_branch_name}" >"$actual" ) && test_cmp expected "$actual" ' test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty index' ' - printf "BEFORE: (${c_green}master${c_clear} ${c_green}+${c_clear}):AFTER" >expected && + printf "BEFORE: (${c_green}\${__git_ps1_branch_name}${c_clear} ${c_green}+${c_clear}):AFTER\\nmaster" >expected && echo "dirty" >file && test_when_finished "git reset --hard" && git add -u && @@ -506,13 +506,13 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt GIT_PS1_SHOWDIRTYSTATE=y && GIT_PS1_SHOWCOLORHINTS=y && __git_ps1 "BEFORE:" ":AFTER" && - printf "%s" "$PS1" >"$actual" + printf "%s\\n%s" "$PS1" "${__git_ps1_branch_name}" >"$actual" ) && test_cmp expected "$actual" ' test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty index and worktree' ' - printf "BEFORE: (${c_green}master${c_clear} ${c_red}*${c_green}+${c_clear}):AFTER" >expected && + printf "BEFORE: (${c_green}\${__git_ps1_branch_name}${c_clear} ${c_red}*${c_green}+${c_clear}):AFTER\\nmaster" >expected && echo "dirty index" >file && test_when_finished "git reset --hard" && git add -u && @@ -521,25 +521,25 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt GIT_PS1_SHOWCOLORHINTS=y && GIT_PS1_SHOWDIRTYSTATE=y && __git_ps1 "BEFORE:" ":AFTER" && - printf "%s" "$PS1" >"$actual" + printf "%s\\n%s" "$PS1" "${__git_ps1_branch_name}" >"$actual" ) && test_cmp expected "$actual" ' test_expect_success 'prompt - bash color pc mode - dirty status indicator - before root commit' ' - printf "BEFORE: (${c_green}master${c_clear} ${c_green}#${c_clear}):AFTER" >expected && + printf "BEFORE: (${c_green}\${__git_ps1_branch_name}${c_clear} ${c_green}#${c_clear}):AFTER\\nmaster" >expected && ( GIT_PS1_SHOWDIRTYSTATE=y && GIT_PS1_SHOWCOLORHINTS=y && cd otherrepo && __git_ps1 "BEFORE:" ":AFTER" && - printf "%s" "$PS1" >"$actual" + printf "%s\\n%s" "$PS1" "${__git_ps1_branch_name}" >"$actual" ) && test_cmp expected "$actual" ' test_expect_success 'prompt - bash color pc mode - inside .git directory' ' - printf "BEFORE: (${c_green}GIT_DIR!${c_clear}):AFTER" >expected && + printf "BEFORE: (${c_green}\${__git_ps1_branch_name}${c_clear}):AFTER\\nGIT_DIR!" >expected && echo "dirty" >file && test_when_finished "git reset --hard" && ( @@ -547,13 +547,13 @@ test_expect_success 'prompt - bash color pc mode - inside .git directory' ' GIT_PS1_SHOWCOLORHINTS=y && cd .git && __git_ps1 "BEFORE:" ":AFTER" && - printf "%s" "$PS1" >"$actual" + printf "%s\\n%s" "$PS1" "${__git_ps1_branch_name}" >"$actual" ) && test_cmp expected "$actual" ' test_expect_success 'prompt - bash color pc mode - stash status indicator' ' - printf "BEFORE: (${c_green}master${c_clear} ${c_lblue}\$${c_clear}):AFTER" >expected && + printf "BEFORE: (${c_green}\${__git_ps1_branch_name}${c_clear} ${c_lblue}\$${c_clear}):AFTER\\nmaster" >expected && echo 2 >file && git stash && test_when_finished "git stash drop" && @@ -561,29 +561,29 @@ test_expect_success 'prompt - bash color pc mode - stash status indicator' ' GIT_PS1_SHOWSTASHSTATE=y && GIT_PS1_SHOWCOLORHINTS=y && __git_ps1 "BEFORE:" ":AFTER" && - printf "%s" "$PS1" >"$actual" + printf "%s\\n%s" "$PS1" "${__git_ps1_branch_name}" >"$actual" ) && test_cmp expected "$actual" ' test_expect_success 'prompt - bash color pc mode - untracked files status indicator' ' - printf "BEFORE: (${c_green}master${c_clear} ${c_red}%%${c_clear}):AFTER" >expected && + printf "BEFORE: (${c_green}\${__git_ps1_branch_name}${c_clear} ${c_red}%%${c_clear}):AFTER\\nmaster" >expected && ( GIT_PS1_SHOWUNTRACKEDFILES=y && GIT_PS1_SHOWCOLORHINTS=y && __git_ps1 "BEFORE:" ":AFTER" && - printf "%s" "$PS1" >"$actual" + printf "%s\\n%s" "$PS1" "${__git_ps1_branch_name}" >"$actual" ) && test_cmp expected "$actual" ' test_expect_success 'prompt - zsh color pc mode' ' - printf "BEFORE: (%%F{green}master%%f):AFTER" >expected && + printf "BEFORE: (%%F{green}\${__git_ps1_branch_name}%%f):AFTER\\nmaster" >expected && ( ZSH_VERSION=5.0.0 && GIT_PS1_SHOWCOLORHINTS=y && __git_ps1 "BEFORE:" ":AFTER" >"$actual" - printf "%s" "$PS1" >"$actual" + printf "%s\\n%s" "$PS1" "${__git_ps1_branch_name}" >"$actual" ) && test_cmp expected "$actual" ' -- 1.9.2 ``` ## Michael Haggerty, 2014-04-22 08:38 Subject: Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1 Message-ID: <53562A96.6000002@alum.mit.edu> URL: https://gitlist.dev/e/53562A96.6000002%40alum.mit.edu In-Reply-To: <20140421202454.GA6062@sigill.intra.peff.net> ``` 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/ ``` ## Junio C Hamano, 2014-04-22 17:38 Subject: Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1 Message-ID: URL: https://gitlist.dev/e/xmqqy4yx5knw.fsf%40gitster.dls.corp.google.com In-Reply-To: <53562A96.6000002@alum.mit.edu> ``` Michael Haggerty 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). ``` ## Richard Hansen, 2014-04-22 18:38 Subject: Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1 Message-ID: <5356B71A.6070500@bbn.com> URL: https://gitlist.dev/e/5356B71A.6070500%40bbn.com In-Reply-To: ``` On 2014-04-22 13:38, Junio C Hamano wrote: > Michael Haggerty 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 ``` ## Junio C Hamano, 2014-04-22 19:47 Subject: Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1 Message-ID: URL: https://gitlist.dev/e/xmqqr44p4042.fsf%40gitster.dls.corp.google.com In-Reply-To: <5356B71A.6070500@bbn.com> ``` Richard Hansen 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. ```