It is simple to test for yourself.
CVE-2014-6271
CVE-2014-6271 is the original shellshock bug. To see if you are vulnerable, run this code at the bash command prompt:
env VAR='() { :;}; echo Bash is vulnerable!' bash -c "echo Bash Test" If the output is:
Bash Test Then you are fine. If, on the other hand, you see:
Bash is vulnerable! Bash Test Then your bash is vulnerable.
CVE-2014-7169
There is a newer related vulnerability. To test for this one, run this code:
env X='() { (a)=>\' sh -c "echo date"; cat echo If you see the following output:
date cat: echo: No such file or directory Then you are fine.
All versions of bash up through 4.3, which is the current version, were vulnerable to shellshock. Since patches keep getting updated, updating your version is probably a good idea.
Who is vulnerable?
According to Qualys, remote exploitation of shellshock may be possible in the following situations:
- 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)
- 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.
- 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.
To be vulnerable on Windows, however, one would have to be using a version of one of the above service that invokes bash.