Home / hosting /

Shellshock Bash Bug – The importance of Server Management

Shellshock Bash Bug – The importance of Server Management

by Alban Taraire

Broken shellAs you might be aware, a critical bug just has been uncovered that puts an incredible number of systems at risk. The main targets are Mac and Linux systems, the latter being the most commonly used for web servers (the machines that run all your favorite websites).

Well, that’s easy, just patch it, would you say. Yes, a patch exists, however things might not be as simple as that. In the real world, countless systems are set in a “fire-and-forget”  mode where patches are applied from times to times, and systems rarely completely upgraded.

There can be many reasons for that.

One being that common, non-enterprise Linux distributions have a relatively short life-time, usually one or two years. That means if your system is older than that (and many are), even if you patched it regularly, you might be out-of-luck for Shellshock as your distribution will not patch these older systems anymore.

Another reason is that software developers tend to develop for a specific version of their framework software (the tools with which they build their own software, like assembling Lego bricks), at a specific time, and upgrading the underlying system might install new versions that break functionality.

Now, who keeps the same website around for more than 2 years, you might ask. Well, more than you might think. The web isn’t only made of public-facing, fancy websites that live or die on their content updates.

For example, many companies run their ERP online, so that it can be accessed by roaming salesmen, suppliers, or clients. Knowing that the implementation of a good-sized ERP can take one or two years, it’s easy to understand that nobody wants to have to run complete system upgrades every year. And if your ERP of choice happens to run on a mature version of a given framework, there are chances indeed that a complete system upgrade might break things.

When you consider your options for Hosting solution, you have a choice between being provided with just a box, power and internet access, or have professional interlocutors who can assist you with real system management, help you upgrade your systems and discuss technical aspects with your developers.

Choosing the “box” solution can work if you have your own team of experts who can handle this. If you don’t, then remember Heartbleed, Shellshock and more to come.

What works today will break tomorrow. It’s not a very worrying thought, as long as you’re prepared.

Now, for Shellshock itself, some recommendations from Red Hat, the leading Enterprise Linux vendor:

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:

vulnerable
this is a test

What if you are vulnerable but your distribution doesn’t provide a patch for bash?

Workaround: Using mod_security:

The following mod_security rules can be used to reject HTTP requests containing data that may be interpreted by Bash as a function definition if set in its environment. They can be used to block attacks against web services, such as attacks against CGI applications outlined above.

Request Header values:

SecRule REQUEST_HEADERS "^() {" "phase:1,deny,id:1000000,t:urlDecode,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

SERVER_PROTOCOL values:

SecRule REQUEST_LINE "() {" "phase:1,deny,id:1000001,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

GET/POST names:

SecRule ARGS_NAMES "^() {" "phase:2,deny,id:1000002,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

GET/POST values:

SecRule ARGS "^() {" "phase:2,deny,id:1000003,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

File names for uploads:

SecRule  FILES_NAMES "^() {"  "phase:2,deny,id:1000004,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271  - Bash Attack'"

It is possible, however unlikely, that these rules may result in false positives. These false positives, along with actual attempts, could result in log files of significant size.

https://access.redhat.com/articles/1200223

Share this article

Leave a comment

Your email address will not be published. Required fields are marked *