The story: a Bash vulnerability has been reported as CVE-2014-6271 and later as CVE-2014-7169 (as it was uncompletely fixed). It allows arbitrary code execution when the content of a variable is parsed, that is, every now and then in shell scripts. If the content of the variable comes from user input, then this is a way for the user to execute arbitrary code, with current local rights.
One way this can be exploited is via Apache CGI (or nginx CGI). These have been provenly found to be exploited on the web, so this is no unnecessary crying wolf. CGI uses shell (Bash) to parse web request headers such as Host or User-Agent and allows arbitrary code execution with the administrative rights of the web server daemon itself. I succeeded in exploiting it for audit purposes, showing there is no need to be a lifelong-expert to proceed.
Although exploits of this vulnerability have reportedly been spotted only by use of Apache/nginx CGI, there could very well be other exploits of any server that uses Bash to parse user input, which means virtually any server undex Unix/Linux (think: Apache without CGI, cups, postfix, databases...)
The following command, launched from a server Bash shell, let's you know if the server is vulnerable to this vulnerability. Unless you did something specific in the last days, it's highly unlikely that your server will not be vulnerable.
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
So, I dearly recommend to patch Bash itself. If you cannot patch or must delay patch application, making sure no CGI scripts are exposed or CGI is disabled is a temporary workaround.
Posts
