[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: REGRESSION: shellshock patch rejects valid function names

From: Stephane Chazelas
Subject: Re: REGRESSION: shellshock patch rejects valid function names
Date: Tue, 30 Sep 2014 17:06:22 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

2014-09-30 09:04:28 -0600, Eric Blake:
> On 09/30/2014 08:42 AM, Eric Blake wrote:
> > Thanks; here's another ksh bug:
> > 
> > $ env 'a|b=' bash -c 'set | grep a"."b'
> > $ env 'a|b=' ksh -c 'set | grep a"."b'
> > a|b=''
> > 
> > But per the documentation of set, "If no options or arguments are
> > specified, set shall write the names and values of all shell variables
> > in the collation sequence of the current locale." 
> Or, reading further, "The output shall be suitable for reinput to the
> shell, setting or resetting, as far as possible, the variables that are
> currently set;"
> but with the current output of set, trying to invoke 'eval "$(set)"'
> will end up executing the command 'a' in the current working directory
> rather than setting the "variable" "a|b".  While the bash Shell Shock
> bug has already established that arbitrary environment variable names
> are a far less likely attack vector than arbitrary environment variable
> values, I still can't help but wonder if someone can come up with an
> exploit where a ksh script that runs with elevated privileges and tries
> to eval the output of set will end up running code of the caller's choice.

Same with "export -p":

$ env -i $'a\necho test\na=b' ksh -c 'export -p' | ksh

And bash is also vulnerable.

$ env -i $'a\necho test\na=b' bash -c 'export -p'
declare -x OLDPWD
declare -x PWD="/home/stephane"
declare -x SHLVL="1"
declare -x a
echo test

(that output doesn't make much sense, suggesting it may also
hide more bugs and vulnerabilities).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]