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:26:12 +1000

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]