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 <[email protected]> wrote: > On Wed, Oct 1, 2014 at 4:59 PM, Tom Metro <[email protected]> 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 > [email protected] > https://www.linkedin.com/in/n1vux > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.blu.org/mailman/listinfo/discuss > -- John Abreau / Executive Director, Boston Linux & Unix Email [email protected] / WWW http://www.abreau.net / PGP-Key-ID 0x920063C6 PGP-Key-Fingerprint A5AD 6BE1 FEFE 8E4F 5C23 C2D0 E885 E17C 9200 63C6 _______________________________________________ Discuss mailing list [email protected] http://lists.blu.org/mailman/listinfo/discuss
