[Cialug] Shellshock Bash Remote Code Execution Vulnerability

Scott Yates Scott at yatesframe.com
Thu Sep 25 15:57:19 CDT 2014


Very good point, though it still feels like a smarter way to approach the
problem if you can limit the exposure and use of client submitted data.


On Thu, Sep 25, 2014 at 3:52 PM, Zachary Kotlarek <zach at kotlarek.com> wrote:

>
> On Sep 25, 2014, at 12:40 PM, Scott Yates <Scott at yatesframe.com> wrote:
>
> > I am saying: It seems like a very bad idea to put arbitrary client
> supplied
> > data into environment variables.  Push them to programs via files, or
> > pipes, or FIFO buffers, but keeping them separated from the system level
> > environment seems like a better way to handle it.  Even if you have to
> > write some wrapper code to handle the data exchange.
>
>
> On linux (and many other systems) environmental variables are local to a
> program’s execution context and are not system-level. There is no way to
> push environmental variables “up” from the current program into any parent
> or global context. And they have no inherently special meaning or function
> beyond that of things like STDERR; they are just a key-value store made
> available for a process to stash data for itself and/or future children.
> There are a couple of exceptions in that you can modify the behavior of the
> dynamic linker or compiler before the program is loaded (and mod_cgi *does*
> filter these), but generally speaking programs are 100% in control of what
> environmental variables mean to them, if anything, and should be
> responsible for handling unexpected data in these just like they would from
> any other data source. Which is why this issue is listed as bash
> vulnerability and not a mod_cgi vulnerability.
>
> And regardless of the data transfer method you'd still need to do
> filtering at some point to keep out “bad" things — bash will just as
> happily execute code beyond function definitions imported from a file or
> entered interactively as it will from the environment — and that filtering
> still needs to be program-specific.
>
>         Zach
>
>
> _______________________________________________
> Cialug mailing list
> Cialug at cialug.org
> http://cialug.org/mailman/listinfo/cialug
>
>


More information about the Cialug mailing list