bug-bash
[Top][All Lists]
Advanced

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

Re: Bash-4.3 Official Patch 27


From: Jon Seymour
Subject: Re: Bash-4.3 Official Patch 27
Date: Mon, 29 Sep 2014 02:30:49 +1000

| correction:  variable called "/tmp/exploit=me"  => a variable called
"/tmp/exploit" with a value "me"

On Mon, Sep 29, 2014 at 2:26 AM, Jon Seymour <jon.seymour@gmail.com> wrote:
> To clarify, I am not sure that the presence of a variable called
> "/tmp/exploit=me" represents a huge vuilnerability for at(1) since
> anyone who can arrange for this to happen can probably mutate the
> user's environment in anyway they choose, but I did want to point out
> that atrun will attempt to execute '/tmp/exploit=me' as a /bin/sh
> command and should there be a executable file at that path, then an
> unexpected execution may result.
>
> I note that my OSX environment currently contains this variable
> injected by Chrome:
>
> COM_GOOGLE_CHROME_FRAMEWORK_SERVICE_PROCESS/USERS/JONSEYMOUR/LIBRARY/APPLICATION_SUPPORT/GOOGLE/CHROME_SOCKET=/tmp/launch-5VzA1C/ServiceProcessSocket
>
> and attempts to invoke 'at' result in unexpected attempts to execute a
> file called:
>
> COM_GOOGLE_CHROME_FRAMEWORK_SERVICE_PROCESS/USERS/JONSEYMOUR/LIBRARY/APPLICATION_SUPPORT/GOOGLE/CHROME_SOCKET=/tmp/launch-5VzA1C/ServiceProcessSocket
>
> when 'atrun' runs. Of course, to exploit this, the attacker would have
> to be able to create a file of that name on the filesystem and enable
> 'atrun' (which is apparently disabled by default on OSX).
>
>
>
> On Mon, Sep 29, 2014 at 2:10 AM,  <becker.rg@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.



reply via email to

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