How to test Shellshock Bash Bug

Must Know

Recently a Bash Code Injection Vulnerability or Bash remote command injection bug Shellshock bash was announced in the computer program ‘bash’ (ref CVE-2014-6271). This vulnerability enables unauthenticated users to run arbitrary commands, and in some configurations remote code execution is possible. This has been scored the highest possible threat ratings by independent security research bodies, including NIST, for both impact and exploitability. Bash is a standard program installed on most machines running non-Windows operating systems as standard including, but not limited to, Unix, Linux, MacOS and many embedded architecture devices. The affected versions go back to bash 1.14 which was first released in ~1995. Unlike the Heartbleed vulnerability which affected only openssl (an additional program that only certain users actually implemented), SHELLSHOCK is likely to affect a much wider community.

How does this impact systems

This issue affects all products which use the Bash shell and parse values of environment variables. This 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.

The patch for CVE-2014-7169 introduces changes to how Bash evaluates environment variables. Applications which directly create Bash functions as environment variables need to be made aware of these changes. Previously, a function had to be stored in an environment variable of the same name. For example, the function “compute” would be stored in an environment variable named “compute”. With the patch for CVE-2014-7169 applied, it would need to use the name “BASH_FUNC_compute()”. As a result, there are now two pairs of parentheses in the environment string, as in “BASH_FUNC_compute()=() { }”.

Functions written in Bash itself do not need to be changed, even if they are exported with “export -f”. Bash will transparently apply the appropriate naming when exporting, and reverse the process when importing function definitions.

You can check for more info on the details from redhat site.

To test if your version of Bash is vulnerable to this issue, run the following command:

$ env x='() { :;}; echo vulnerable'  bash -c "echo this is a test"

If the output of the above command looks as follows:

this is a test

you are using a Shellshock bash 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

You can get more information about the shellshock bash bug here in RedHat site.

Even there is a online site to partially test the shellshock bug using your url if its exposed to internet

In case of any ©Copyright or missing credits issue please check CopyRights page for faster resolutions.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.