[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.
Re: Bash-4.3 Official Patch 27, Chet Ramey, 2014/09/28
Message not available