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.