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. ) _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss