| 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.seym...@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...@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.