What Can Shared Hosting and VPS Users Do About Shellshock?

If you follow tech news at all, you have by now probably heard about the “Shellshock” vulnerability affecting Bash across all Linux, BSD, and Unix variants that use the shell program. For dedicated server users, the solution is quite simple, install the latest patched version of Bash. The question that remains, however, is what, if anything hosting users who do not have their own servers can do to prevent falling prey to exploits of Shellshock?

VPS users will typically be able to update their virtual private servers just as dedicated server users would. That means, they can log into their servers via SSH, check for the vulnerability and install the patch. Shared hosting users do not have that luxury and are pretty much at the mercy of their web hosting providers.

What you can do

The first thing you need to do is check your web hosting provider’s news and social media feeds to see if they have published any information about fixing the vulnerability. If you are not familiar with your host’s server architecture, now might be a good time to find out. For all you know, they might not even use Bash at all.

If you do not find any information, it is perfectly reasonable to contact your host for clarification. They will likely provide you with a yes or no. If they are not aware of the problem, your notification should convince them to fix it.


Could the Shellshock Vulnerability be the Next Heartbleed?

A vulnerability in the Bourne Again Shell (bash), dubbed “Shellshock,” has become a major security concern and drawn comparisons to the Heartbleed bug. The bash vulnerability scored a 10 on the Common Vulnerability Scoring System (CVSS), and an initial patch did not effectively address the flaw.

The OS command injection vulnerability was made public on Wednesday after being discovered by Stephane Chazelas of Akamai last week. As a Unix shell flaw, Shellshock could affect any computer running Linux or Mac OS, however Josh Bressers, RedHat Product Security Team Leader told Threatpost that the vulnerability applies only to very specific conditions which are not common.

Despite this, the risk is considered high, as the type of vulnerability offers more control to an attacker exploiting it than an OpenSSL bug like Heartbleed. Andy Ellis, Chief Security Officer of Akamai, notes in a blog post that Shellshock, with its original failed attempt at a fix, “presents an unusually complex threat landscape as it is an industry-wide risk.”

Read More

The Cloud is not magical

Thinking the cloud is magical with 100% uptime ? Think again.

Amazon will tomorrow begin a bloody global reboot of its Elastic Compute Cloud (EC2) compute instances after it found a security bug within the Xen virtualisation platform.

The rolling minutes-long reboots would be completed by 30 September. Amazon did not name the reason for the upgrade, widely thought to be a security issue affecting underlying hosts.

Tech site ITNews cited an unnamed source who said the reboot was due to an unspecified vulnerability in the open-source Xen-108 platform. Later, Xen and Amazon confirmed a fix for a non-disclosed security flaw is due to be released on October 1.

Reboots made prior to the patch blitz would not guarantee connection to a patched host unlike previous maintenance updates.

Thorsten von Eicken, founder of Rightscale which manages AWS work loads, said EC2 users should monitor their ‘events’ page within the AWS console for the most reliable updates.

“For instances where a short reboot is safe and acceptable, you don’t need to do anything: They will simply reboot during maintenance and stay on the same host with the same ephemeral disks and the same IP address,” von Eicken said.

“For databases, if you have set up the recommended master-slave configuration across AZs, you have the option to reboot the impacted AZ ahead of the maintenance window in an attempt to get an instance that is already patched.” Read More