[Discuss] Shellshock

[jabr at blu.org (John Abreau)]

Seems to me that changing the /bin/sh symlink to point to dash instead of
bash should ameliorate the problem, at least where scripts that invoke
/bin/sh don't depend on bash features.

Of course, finding all such sloppily-written scripts on an existing server
could be a big chore.
Once found, they can at least be normalized by adding "#! /bin/bash" so
they continue to
function the way they already were before changing the symlink to point to
dash.


On Wed, Oct 1, 2014 at 5:33 PM, Bill Ricker <bill.n1vux at gmail.com> wrote:

> On Wed, Oct 1, 2014 at 4:59 PM, Tom Metro <tmetro+blu at gmail.com> wrote:
> > But in the case of CGI you are just moving the network/local
> > barrier a bit further down the stack.
>
> and moved it right through system() => /bin/sh => /bin/bash by alias
> which last wasn't designed to be network secure.
>
> > The CGI code is written with the
> > expectation that the inputs are tainted.
>
> alas, that paranoia (even if correctly implemented, which even Perl
> Taint doesn't guarantee, only that something is tried) is only *after*
> system() gives unclean ENV to bash to pass to Perl.
>
> [ Efficient CGI implementations using pool processes and RPC for
> non-spawning CGI emulation avoid *this* problem, plenty of other room
> for trouble. ]
>
> --
> Bill Ricker
> bill.n1vux at gmail.com
> https://www.linkedin.com/in/n1vux
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>



-- 
John Abreau / Executive Director, Boston Linux & Unix
Email jabr at blu.org / WWW http://www.abreau.net / PGP-Key-ID 0x920063C6
PGP-Key-Fingerprint A5AD 6BE1 FEFE 8E4F 5C23  C2D0 E885 E17C 9200 63C6