Shellshock Vulnerability CVE-2014-6271

The Bash Shell have a new exploit named shellshock.

From Thursday 25 september 2014, Bash have a bug that realy make everybody paranoid. The exploit is CVE-2014-6271 which enable the attacker to run any code even without authenticating to the server, especially with DHCP services.

Stephane Chazelas discoverd this vulnerability in bash, related with the how the environment variables are processed by bash and this affect many of the linux / unix system which by default utilize bash shell. This affect Bash released 20years ago back to version 1.3

Lucky for me, i am in the BSD bandwagon, which by default not using Bash, but using tcsh or csh, which licensed under BSD license term. The reason Bash not a default install in BSD system because Bash is use GPL Licensing term.
But i don't know if this will change if Bash using BSD license, but i think because Bash was develop with no security in mind. Yeay Go BSD :)

But some servers use bash need to update. First you can test it with the command.

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

if the output print out vulnerable, then you need to upgrade your bash version to the latest. Redhat, Debian, Ubuntu, and all major Linux Distro already release a fix for this, but only days, the fix show that it only prevent no all the bug, like Redhat said in the website.

But still better patch first, as a first step for prevent the vulnerability. Also there are many test utility for this shellshock in the web. One that i found was Shellshock HTTP Test and Shellshock Vulnerability Test

Now for the update , in debian system you just run this command :

$sudo apt-get update && sudo apt-get install --only-upgrade bash

In Centos / Redhat system :

$sudo yum update bash

or download the rpm file with this command (in Centos 5.10) :

$ wget ftp://fr2.rpmfind.net/linux/centos/5.10/updates/i386/RPMS/bash-3.2-33.el5-10.4.i386.rpm

$sudo yum --nogpgcheck update bash-3.2-33.el5-10.4.i386.rpm

This Shellshock worse than last openssl vulnerability, because many old system affected like the cgi web server processing services. But in modern web application i had test, which running python, not affected by the shellshocks because not using Bash shell.

Read More

Control Cache directive for Web Server

When dealing with a Web application, the web server is our gateway to the application server. The best practice to separate the load between application code and static files are the task of the web server. This to make sure the application server just handle the thing they good of, the application.  Let the burden to handle the serving of static files be lifted from the application server. Have mercy for the application server.

So the best practice is the static files handled by web server directly, and the application generated content goes to the application server. Now the load already separated. Now to get more of your application speed, we want to control how long the static files get cache by the client browser.

The question is can this be done? Yes this is can be done, this is included in the HTTP protocol specification rfc7231. We can control how long the request result will be cached by user web browser, and newer web browser will respect this header if ever appear in the http request results.

So the directive can be use are :

cache-control: private, max-age=0, no-cache

This means cache-control is active.

The private directive means the request should not be cache by shared cache like proxy server. But the local private cache can do the caching.

Max-age means the maximum age of the request result that considered valid since first request result arrived in client and can be used by the client.

no-cache means don't do any caching in client web browser. The browser will always fetch the new content from the web server.

Note if you want to increase the max-age, then remove the no-cache directive.

This can be applied to any webserver, including Microsoft IIS without change anything in the registry. The same with Nginx or apache or lighttpd.

Good luck and happy serving web content.

Read More