[Discuss] Shellshock

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

I take exception to the Lisp.org quote.

Yes, it's a fair point that Gnu project is older than either Apache or
Linux, but that doesn't exempt Bash from criticism. (And if this bug
is only 20 years old as claimed, being when ENV function overrides
were invented, it's maybe a year older than Apache.)

Alas there is both a mis-guided feature and at least one bug in the
feature (even assuming its intent ever made any sense)  -- as well as
the environmental / combination problems.

[ The misbegotten feature is useful for Code Injection for callbacks /
genericization. It's great for a major programming language/framework
but not for security-critical components. Code Injection should cross
security boundaries only with the utmost care if at all. ]

Code fuzzed on the ENV value *after* the function definition should
not have been accepted at all. Executing it at function def time is a
bug.

Crucially, they never should have linked /bin/sh=>bash .
   That was lazy, they didn't want to maintain legacy shell and the new bash.
   It presumed it would always be sufficiently backward compatible.
   Exposed as false.
   Code injection in a critical gut component like /bin/sh ...
implemented with a link. Oops !
   It was NEVER safe either. even without Apache.  Any Setuid binary
that used system() might pass ENV to BASH even though it was coded
initially on pre-BASH POSIX UNIX. Whether env 'ls="(){exploit}'
rootprogram is considered a misfeature or bug, it's a capability that
has no place in critical infrastructure like /bin/sh. Never. Disaster
was lurking even then, probably was used.
   (That SETUID binaries really never should have used system() with a
purged $PATH instead of using explicit trusted pathname and discrete
arg list on execX() is tangential. It's so convenient you can't keep
folks from doing it. :-(  That means /bin/sh has to be simple enough
to be trusted -- as it once was. Not some feature rich bloat.)

Debian+Ubuntu since 2009 are mostly immune since /bin/sh was switched
to lighter weight /bin/dash then. Dash is like old SH but less ugly?
(They're still exposed via DHCP but AFAIK that's a LAN-or-Mouse attack
not something that can traverse firewalls like :80.)

Most of the embedded devices mentioned in Chicken-Little reports
*pretend* to have 'bash' but really link both /bin/sh and /bin/bash to
busybox,  to which all the 'external' commands also link. Safe,
different code base.

Note that Multiple additional BASH security bugs have been found
and/or fixed since they started looking harder in the last week.

Keep patching.

( And check if you've got mystery back doors loaded in the intervening
week, if you have exposed ports. )