[Discuss] Shellshock

[bill.n1vux at gmail.com (Bill Ricker)]

On Wed, Oct 1, 2014 at 5:34 PM, John Hall <johnhall2.0 at gmail.com> wrote:
> It also that shellshock  would not apply to scripts in one language that
> use a subprocess for some functionality like a script in python or ruby
> that uses results from a perl or even a bash script, as long as any data
> that is passed went thorough normal sanitation measures.

That depends how the call to the second script is made. If as usual it
is by system() with single arg, or `` rather than by fork/exec(),
system(3) will still call /bin/sh to find program on $PATH and parse
ARGS.  That  gives /bin/bash first exposure to all ENV before the
child gets to sanitize, on those systems where the ongoing error of
linking simple legacy POSIX /bin/sh to huge Gnu /bin/bash is in force
(ash, actual classic sh, dash, busybox as sh are all fine *this
time*).

Only if the spawn uses the LIST form of exec() or system()  with a
hard pathname for the subscript -- not the `backtick` form !! --
/bin/sh is avoided and this vulnerability avoided on interlanguage
subscripting.

HOWEVER, proper untainting doesn't make a BASH subscript safe from the
original ShellScript bug due to the
   env funcname='(){body;}' script args
feature to override functions in ENV. This is designed for code
injection callbacks, but also serves as exploitable code injunction
via
   env funcname='(){body;} erroneous syntax exploit code executed
early;' script args
The "erroneous syntax exploit code executed early" will execute
*before* your script, during parser time, unless you have the BASH
patches.

This affects dhcp-client on debian (where system(3) uses sh=>dash)
because dhcp-client is #! /bin/bash; but threat requires attacker can
has a dhcp-server on your lan via some other exploit, isn't coming in
the NAT/firewall into your public HTTPD like mod_cli.

> But there are serious problems with mod_cgi

YES, because it uses system(3) as above (and defers newtork data
sanitization to child).
But any program doing likewise ... there are many ... is equally at risk.

> This article by trend micro makes it clear that data sanitization is
> useless if mod_cgi is enabled for Apache. It uses bash and environment
> variables to execute your app in the first place so any sanitization code
> in the script is useless.

Exactly.

> Question: who uses mod_cgi in production???

Many websites *started* that way, even in public Beta.
Most switched when volume hit (if they didn't wither for lack of
volume), as spawning a process per request is not scalable ... and
it's the system(3) spawn that is both slow-non-scalable *and* unsafe
passing of network data through BASH !

I had one mod_cgi still in Production last i knew ... but not exposed
outside the NAT. Quick and dirty replacement for a defunct vendor
product until final replacement ready, which would be unlikely to ever
get 10 requests per minute. We still performance tested it and assured
folks that if it ever had a performance problem we could move it to
fastcgi.

but the real danger is little admin websites on the side of your
server. These may not have evolved beyond mod_cgi, since it would be a
problem if more than one sysadmin logged in anyway. The notorious
reported examples of surviving, widespread mod_cgi are CPanel and
CUPS. I hope your CUPS admin isn't exposed by your firewall.  But
CPanel must be exposed to the wider internet if providing wordpress or
other multi-tenant sites using it to the public.

There was much hype that the toy websites in routers and NAS
appliances would be an incurable problem for Shell-Shock, but even if
they are mod_cgi, they're nearly all using (/bin/sh, /bin/bash) =>
busybox alias. They sometimes APPEAR to have a bash, but do not, as
it's too bloated for embedded use.
 (Cheapness made a good security decision for once.)
-- 
Bill Ricker
bill.n1vux at gmail.com
https://www.linkedin.com/in/n1vux