[Top][All Lists]

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

Re: REGRESSION: shellshock patch rejects valid function names

From: Eric Blake
Subject: Re: REGRESSION: shellshock patch rejects valid function names
Date: Tue, 30 Sep 2014 09:04:28 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1

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.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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