I had honestly not noticed the “shell shock” vulnerability until a breathless post on LinkedIn alerted me. ‘Deadly serious’ comes a tweet, “10% of world’s computers are at risk”…. Blog posts, and headlines and tweets, oh my!
My immediate reaction was, “who trusts bash, or any shell, with sensitive execution?”
On checking some of the sources, I am really disappointed.
First off, let’s jail the usual suspects: the security consultants. Just as with “heartbleed,” the first step with “shellshock” was to find a good name with which to market it.
Second off, let’s stop blaming the victim. If cgi-bin or Tomcat or dhcp or even inetd call bash, aren’t they responsible? Bash is not SUID – it can’t change its permissions. I don’t blame SQL Server for SQL injection – I blame the idiot web programmer. In the same way, any “Shellshock” exploit is completely due to the programs that call bash, not the fact that bash doesn’t second guess them.
Third off, what idiot at CERT gave a level 10 risk rating to a non-SUID executable that is not directly callable from outside the “vulnerable” host?
Fourth off, why are the Linux vendors jumping up and raising their hands to say “I’m guilty”? Redhat, Ubuntu, Debian, who’s next?
Fifth off, hasn’t anyone considered the following remediation alternative?
- chsh -s /bin/zsh root daemon uucp lp mailman apache
- for oh_no in $(ls /bin/sh /bin/bash); do chmod -x $oh_no; mv $oh_no $(dirname $oh_no)/OH_NO_$(base name $oh_no); ln /bin/zsh $oh_no; done
It is kinda nutty to treat a code injection attack on a base utility on the utility rather than on the poorly-programmed vectors.
I have to say I have been inconsistent about this. I really don’t feel comfortable putting shell calls into server-style code with escalated privileges. But I haven’t looked much at it, either. And now I will. And if I find a problem, I’ll won’t look at FSF/GNU for the blame – I’ll check the mirror.