Skip to content ↓ | Skip to navigation ↓

A remotely exploitable vulnerability has been found by a researcher at Akamai (CVE-2014-6271) in Bash affecting most Linux distributions, according to Akamai:

This vulnerability in bash allows an adversary who can pass commands to bash to execute arbitrary code. As bash is a common shell for evaluating and executing commands from other programs, this vulnerability may affect many applications that evaluate user input, and call other applications via a shell… this impacts any system that uses a vulnerable bash.
We have also verified that this vulnerability is exposed in ssh—but only to authenticated sessions. Web applications like cgi-scripts may be vulnerable based on a number of factors; including calling other applications through a shell, or evaluating sections of code through a shell.

The vulnerability is caused by the ability to create environment variables with values before calling the bash shell. The variables that are passed can contain code, which are executed before the shell is actually invoked. The vulnerability is then exposed in the ability to add extra code to the end of these functions.

This is a massive vulnerability given the number of devices that are effected. Linux not only runs the majority of the servers that power the Internet but also a majority of embedded devices, including Mac laptops and possibly iPhone and Android devices running the vulnerable version of bash.

This vulnerability is also particularly scary given that nobody knows at this point how far back the vulnerability goes and if it may have been exploitable prior to discovery. I ran a test on a Mac and sure enough, the values returned show it is vulnerable:


In a blog post by Redhat, Huzaifa Sidhpurwala posted several potential scenarios that could leverage this vulnerability:

  • ForceCommand is used in sshd configs to provide limited command execution capabilities for remote users. This flaw can be used to bypass that and provide arbitrary command execution. Some Git and Subversion deployments use such restricted shells. Regular use of OpenSSH is not affected because users already have shell access.
  • Apache server using mod_cgi or mod_cgid are affected if CGI scripts are either written in bash, or spawn subshells. Such subshells are implicitly used by system/popen in C, by os.system/os.popen in Python, system/exec in PHP (when run in CGI mode), and open/system in Perl if a shell is used (which depends on the command string).
  • PHP scripts executed with mod_php are not affected even if they spawn subshells.
  • DHCP clients invoke shell scripts to configure the system, with values taken from a potentially malicious server. This would allow arbitrary commands to be run, typically as root, on the DHCP client machine.
  • Various daemons and SUID/privileged programs may execute shell scripts with environment variable values set / influenced by the user, which would allow for arbitrary commands to be run.
  • Any other application which is hooked onto a shell or runs a shell script as using bash as the interpreter. Shell scripts which do not export variables are not vulnerable to this issue, even if they process untrusted content and store it in (unexported) shell variables and open subshells.