A flaw was found in the way Bash evaluated certain specially crafted environment variables. An attacker could use this flaw to override or bypass environment restrictions to execute shell commands. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue. In this guide we will show how to check for Shellshock Bash Vulnerability and how to fix it in multiple Linux Operating systems such as Debian based Ubuntu, Linux Mint and Red Hat Based CentOS, Fedora distributions.
The GNU Bourne Again shell (Bash) is a shell and command language interpreter compatible with the Bourne shell (sh). Bash is the default shell for Red Hat Enterprise Linux. Red Hat (and rest of the open source community) would like to thank Stephane Chazelas for reporting this issue.
All bash users are advised to upgrade to these updated packages, which contain a back-ported patch to correct this issue.
The Shellshock vulnerability can be exploited on systems that are running Services or applications that allow unauthorized remote users to assign Bash environment variables. Examples of exploitable systems include the following:
- Apache HTTP Servers that use CGI scripts (via
mod_cgi
andmod_cgid
) that are written in Bash or launch to Bash sub-shells - Certain DHCP clients
- Open SSH servers that use the
ForceCommand
capability - Various network-exposed services that use Bash
For additional information on the CVE-2014-6271 and CVE-2014-7169. flaw, refer to the Knowledge base article at https://access.redhat.com/articles/1200223
How to check for Shellshock Bash Vulnerability?
On each of your systems that run Bash, you may check for Shellshock vulnerability by running the following command at the bash prompt:
env VAR='() { :;}; echo Bash is vulnerable!' bash -c "echo Bash is not vulnerable"
If you see output that looks like Bash is not vulnerable
, your version of Bash is safe:
Sample output
root@kali [~]# env VAR='() { :;}; echo Bash is vulnerable!' bash -c "echo Bash is not vulnerable"
Bash is not vulnerable
If you see Bash is vulnerable!
as is some part of your output, you MUUST update your Bash. It means a remote attacker could inject malicious code, following a function definition within an environment variable assignment.
Test website for Shellshock Bash Vulnerability
Following 3 sites are useful when you want to test a site for Shellshock Bash Vulnerability
Fix Shellshock Bash Vulnerability by updating Bash
The easiest way to fix the vulnerability is to use your default package manager to update the version of Bash.
Note: At the time of writing, only an “incomplete fix” for the vulnerability has been released. As such, it is recommended to update your machines that run Bash immediately, and check back for updates and a complete fix.
aptitude / apt-get: Debian based distro (i.e. Ubuntu, Linux Mint, Kali etc.)
Update Bash to the latest version available via apt-get
sudo apt-get update && sudo apt-get install --only-upgrade bash
(or)
apt-get update && sudo apt-get install --only-upgrade bash
Now run check your system vulnerability again by running the command in the previous section.
yum: Red Hat based distro (i.e. Fedora, CentOS etc.)
Update Bash to the latest version available via the yum
sudo yum update bash
(or)
yum update bash
Now run the tests using those 3 websites again.
Links & Resources
- CVE-2014-6271 (BashMash/Shellshock)
- CVE-2014-7169 (BashMash/Shellshock)
- Patch for CentOS (versions 5 through 7) against BashMash
- Patch for Ubuntu 10.04 LTS, 12.04 LTS, and 14.04 LTS against BashMash
- Patch for Debian against BashMash
- PHP scripts executed with mod_php are not affected even if they spawn subshells.
- DefCamp International Security Conference
- Troy Hunt’s excellent post on check for Shellshock Bash Vulnerability.
Ubuntu now has the latest version of Bash sent out to their repositories. More info here:
http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-7169.html
ShellShock Logo Credit: bf5man @ openclipart
Conclusion
Shellshock is probably and truly far worse than HeartBleed vulnerability. Everything (almost) got bash or shell running and in many cases you don’t even know it. Heartbleed allowed remote access to small amount of data in the memory of affected machines. Shellshock is enabling remote code injection of arbitrary commands pre-auth which is potentially far worse.
I am beginning to think that this whole thing is some kind of plot cooked long time back and this was how big brother was watching us … I guess it’s just me.
Thank you for posting this!
Thank you!!
If you’re looking for a shellshock logo I knocked one up for fun here: http://bobmckay.com/i-t-support-networking/shellshock-free-vectored-logo-jpg-png-etc
Thanks for the logo! :-)
How about a tutorial to use this vulnerability, not to fix?
It’s useful for us to reporting.
Thank You…..