On 25 Sep 2014, at 18:27, Pierce Ng <pierce@samadhiweb.com> wrote:
On Sun, Sep 21, 2014 at 06:56:27PM -0400, David T. Lewis wrote:
If you are booting directly into the image, you may find it useful to also load CommandShell/OSProcess into your image. This will let you open a Smalltalk shell window directly within your Squeak/Pharo boot image, so that you have access to the operating system with actually opening any windows or terminal sessions outside of your image.
http://www.squeaksource.com/CommandShell http://www.squeaksource.com/OSProcess
In view of ShellShock, from a PipeableOSProcess example:
| env | env := OSProcess thisOSProcess environment copy. env at: #SHOCKED put: '() { :;}; echo ShellShocked;'. (PipeableOSProcess command: 'echo Nah environment: env) output
This gives the following. (Yes, this is done on an unpatched bash for demo purposes. Everyone should patch as soon as you can.)
ShellShocked Nah
I have a webapp that shells out to some OS command line tool. I think I have written it such that untrustworthy web input does not taint the command line tool's environment and input. I think. Everyone doing similar may wish to relook at it.
It is my understanding that the attack vector is cgi-bin which turns HTTP headers into environment variables, which are then interpreted as functions and executable shell code. [ which is pretty heavy/scary stuff ] If you serve HTTP directly (Zinc/Seaside), or through a proxy (apache2 or nginx), no HTTP headers are turned into environment variables, so invoking a sub shell is safe (unless you make some other error of course). [ anyway, that is what I think ] I disables all cgi[d] modules, we weren't using them anyway. [ but who knows what will turn up ]
David, perhaps the code is already there, but can we run OS commands without invoking the shell?
Pierce