Upgrade Bash and Address CVE-2014-6271 ("Shellshock") now with Scalr

September 24, 2014 Thomas Orozco

Earlier today, it was discovered that bash (the “Bourne-again shell”) was susceptible to remote code execution.

The vulnerability (CVE-2014-6271) is triggered when bash is called with specially-crafted environment variable values (which, unlike environment variable names, aren’t usually validated!).

To check whether a given system is affected, you can run the following command:

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

Just How Bad Is This?

Very bad. Passing user-provided information through environment variables is in fact pretty common (it’s done in CGI scripts with HTTP_* variables for user-provided headers, in SSHD with SSH_ORIGINAL_COMMAND, etc.).

What’s more, on RHEL, bash is the default shell, which means that all your calls to system (e.g. any Python that uses os.system, etc.) go through bash (and are therefore vulnerable). So even if you are not directly using bash, you might still be (indirectly) vulnerable.

If you are using Debian or Ubuntu, your attack surface is slightly more limited, because the default shell is dash, not bash. That is not to say this is a minor vulnerability, though — you should nonetheless upgrade immediately.

Upgrade Bash Now

To upgrade your systems, you can use the following script (use One-Off Script Execution). It’ll detect the package manager you’re using, update bash, and run a test (it’ll exit with 0 if the update was successful, 1 if you’re still vulnerable).

Check your Scripting Logs to ensure that the vulnerability is gone.

 

Ensure the vulnerability doesn’t come back to haunt you!

You can use Global Orchestration (a new Scalr 5.0 feature) to ensure that the aforementioned script runs on all your instances (preferably upon HostInit), so that bash is updated at startup on all your systems.

Update: Bash still vulnerable

The fix released by the bash maintainer earlier today did not entirely address the issue, and you should need run another update (consider updating the is_vulnerable function with the code linked here, which will let you know whether you are still vulnerable).

Does This Vulnerability Affect Scalr?

This vulnerability doesn’t affect Scalr directly, but it does affect the servers you are managing through Scalr.

 

Previous Article
Application Cloud Readiness Checklist
Application Cloud Readiness Checklist

Cloud readiness assessment checklist “Is this app ready to be deployed to cloud?” If your organization i...

Next Article
AWS Massively Rebooting Instances - What you need to know
AWS Massively Rebooting Instances - What you need to know

Earlier today, AWS announced that it would begin rebooting instances across its EC2 service over...

×

Join thousands of Cloud professionals on the Scalr Newsletter

Thank you!
Error - something went wrong!