On 9/28/14, 12:10 PM, becker...@gmail.com wrote:
> On Sunday, September 28, 2014 4:38:24 PM UTC+1, beck...@gmail.com wrote:
> ......
>> If I use the Arch linux [testing] bash-4.3.027-1 which is uses this patch
>> then I have a patch against the at(1) source which converts exported
>> functions into something that sh can parse and allows exported functions to
>> be used in the environment that calls at.
>>
> .......
>
> Jon Seymour asked me if my at patch would fix the following vulnerablity
> (presumably in at(1))
>
> echo pwd | env "/tmp/exploit=me" at tomorrow
>
> which I presume relies on acceptance of /tmp/exploit=me as a possible
> command. I'm not sure it does since the current at code writes the variable
> name out unconditionally (ie no inspection of characters etc etc). I could
> probably raise an error for bad variable names, but I'm not sure I understand
> what characters are now illegal or what the lexical definition of bash/sh
> variable names is now. So I would appreciate advice on that.
Variable names have the same grammar they always have: letters, digits,
underscores, may not start with a digit. It's best to just ignore and
pass along environment strings that you don't recognize.
That's one of the goals of the changes in patch 27: to encode exported
shell function names in a way that won't collide with valid shell variable
names and assignment statements.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
