[Top][All Lists]

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

Re: Bash-4.3 Official Patch 27

From: Chet Ramey
Subject: Re: Bash-4.3 Official Patch 27
Date: Sun, 28 Sep 2014 20:52:49 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 9/28/14, 12:10 PM, address@hidden wrote:
> On Sunday, September 28, 2014 4:38:24 PM UTC+1, address@hidden 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.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

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