26 August 2014

Update on Bash Shell Vulnerability: CVE-2014-6271

Following on from yesterday’s blog, it is very likely that you will have already read about the recent bash shell code injection vulnerability, allowing an attacker to bypass imposed environment restrictions using specially constructed environment variables. This issue affects all products which use the Bash shell and parse values of environment variables. The issue is especially dangerous as there are many possible ways Bash can be called by an application. Quite often if an application executes another binary, Bash is invoked to accomplish this. Because of the pervasive use of the Bash shell, this issue is quite serious and should be treated as such. Exploit code is publicly available and active scans have been detected searching for vulnerable servers. The CIS Alert Level has been raised to level 3 (elevated risk) in response to this emerging threat. Redscan has been proactive by taking the following actions to assist in protecting our customers networks:

  • As soon as the threat was detected we confirmed that the Redscan security gateway was not able to be exploited;
  • Redscan patched the bash shell on the gateway anyway, to provide added assurance;
  • IDP signatures to detect and block some of the possible exploits were pushed to all boxes running enhanced IDP filtering.

It should be noted that it is impossible for the security gateway to detect, and therefore block, all possible exploit mechanisms for this vulnerability. Therefore all customers should analyse their own servers (especially those exposed to the Internet) and either patch the bash shell, or temporarily block access to potentially vulnerable services until a patch becomes available. You should also consider that many network appliances are Linux based and may also be vulnerable, it is recommended that you check with the relevant vendors to determine if firmware updates are needed to address this problem. Note that it has very recently been found that the initial patch for CVE-2014-6271, while good, is not perfect. A subsequent vulnerability has now been found that is not covered by the initial patch. Therefore, check with your vendors that the patch you download covers both CVE-2041-6271 and CVE-2014-7169. If the latter vulnerability is not covered, do not wait for it but patch with the existing update. The latter vulnerability is much less severe than the former, so patching with CVE-2041-6271 is an effective mitigation action.  It will mean you will have to patch again when your vendor produces a patch for CVE-2014-7169. To assist with analysing customer servers, Redscan provides the following information in the hope that it may be of help. The vulnerability arises from the fact that it is possible to create environment variables with specially-crafted values before calling the bash shell. These variables can contain code, which gets executed as soon as the shell is invoked. The name of these crafted variables does not matter, only their contents. As a result, this vulnerability is exposed in many contexts. The following list is not exhaustive, but serves to illustrate some of the attack surfaces to consider:

  • 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 servers 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.
  • 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 using bash as the interpreter. Shell scripts which do not import environment variables are not vulnerable to this issue.

You can test to see if your system’s shell is vulnerable by running the test we outlined yesterday.  This can be found at: https://www.redscan.com/bash-shell-vulnerability-cve-2014-6271/ If you need assistance with blocking access to vulnerable services, or you have any questions, please raise a support ticket or contact the Redscan Security Operations Centre.

back to all posts