Shellshock: Better ‘bash’ patches now available

The first patches for Shellshock didn’t offer complete protection. The latest revisions of this patch for the popular Mac OS X, Linux, and Unix bash shell security problem were released on Friday, offering greater defenses against hackers.

The problem with the first patch, as Red Hat explained in its Shellshock FAQ, was that it only took care of the original bash flaw CVE-2014-6271. This, the true Shellshock bug, is the worst bash security hole. There were also others.

Red Hat said: “Shortly after that issue went public a researcher found a similar flaw that wasn’t blocked by the first fix and this was assigned CVE-2014-7169.” This bug is also a security problem, but it’s not as bad as the other flaw.

Later, Red Hat Product Security researcher Florian Weimer found additional problems and these were designated CVE-2014-7186 and CVE-2014-7187. Fortunately, these bugs are less serious and the latest patch takes care of these as well. As Red Hat’s Huzaifa Sidhpurwala told me: “The latest version of bash fixes all the CVE issues.”

So, what you want to do now, if you haven’t already, is check to see if you’re running a vulnerable version of bash.

Run the following command, created by Red Hat, from your bash shell:

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

If you see the results below, or a variation of this in your output:

vulnerable
bash: BASH_FUNC_x(): line 0: syntax error near unexpected token `)'
bash: BASH_FUNC_x(): line 0: `BASH_FUNC_x() () { :;}; echo vulnerable'
bash: error importing function definition for `BASH_FUNC_x'
test

…then you’re open to Shellshock attacks.

If you see:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
bash: error importing function definition for `BASH_FUNC_x()'
test

…you have a version of bash that has the basic Shellshock patch, but it can still be attacked.

What you want to see is:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `BASH_FUNC_x'
test

…and then you’ll know you have a version that’s Shellshock resistant.

Next, to see if your bash has been patched for the the “7169” trouble, run:

cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo

If you see:

bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
Fri Sep 26 11:49:58 GMT 2014

…with the last line being the current date and time, then you’re still vulnerable to a “7169” attack.

The result you want to see is:

date
cat: /tmp/echo: No such file or directory

If you see the above, you’re good to go. But, if you see the error message with the date and time, immediately check to see if there’s a new patch available for your version of bash.

For Mac server administrators, it’s a different story.

Apple claims that most Mac users are safe from bash attacks. In a statement to sister-site CNET, Apple said OS X systems are safe by default because users “are not exposed to remote exploits of bash unless users configure advanced UNIX services.”

The technology giant added: “We are working to quickly provide a software update for our advanced UNIX users.”

If you’re just running a Mac laptop or desktop, you shouldn’t have any worries. What Apple doesn’t say, but is nonetheless true, is that if you’re running a Mac server to provide network services such as a Web or Dynamic Host Configuration Protocol (DHCP) server, you’re wide open to being attacked.

If you can patch your bash, do it, do it now. Hackers are already looking for unprotected servers. When they find one, they are automatically attacking Web servers, DHCP servers, and other services that call on bash.

Worse still, Rapid7’s Metasploit penetration tool, which has often been used by hackers to attack sites, now has a Shellshock module. With this and similar script-kiddie tools available, expect the number of attacks to increase dramatically because now almost no technical skill is now needed to launch an assault.

The real and present danger is for servers.

According to the National Institute of Standards (NIST), Shellshock scores a perfect 10 for potential impact and exploitability. Red Hat reports that the most common attack vectors are:

  • httpd (Your Web server): CGI [Common-Gateway Interface] scripts are likely affected by this issue: when a CGI script is run by the web server, it uses environment variables to pass data to the script. These environment variables can be controlled by the attacker. If the CGI script calls Bash, the script could execute arbitrary code as the httpd user. mod_php, mod_perl, and mod_python do not use environment variables and we believe they are not affected.
  • Secure Shell (SSH): It is not uncommon to restrict remote commands that a user can run via SSH, such as rsync or git. In these instances, this issue can be used to execute any command, not just the restricted command.
  • dhclient: The Dynamic Host Configuration Protocol Client (dhclient) is used to automatically obtain network configuration information via DHCP. This client uses various environment variables and runs Bash to configure the network interface. Connecting to a malicious DHCP server could allow an attacker to run arbitrary code on the client machine.
  • CUPS (Linux, Unix and Mac OS X’s print server): It is believed that CUPS is affected by this issue. Various user-supplied values are stored in environment variables when cups filters are executed.
  • sudo: Commands run via sudo are not affected by this issue. Sudo specifically looks for environment variables that are also functions. It could still be possible for the running command to set an environment variable that could cause a Bash child process to execute arbitrary code.
  • Firefox: We do not believe Firefox can be forced to set an environment variable in a manner that would allow Bash to run arbitrary commands. It is still advisable to upgrade Bash as it is common to install various plug-ins and extensions that could allow this behavior.
  • PostfixThe Postfix [mail] server will replace various characters with a ?. While the Postfix server does call Bash in a variety of ways, we do not believe an arbitrary environment variable can be set by the server. It is however possible that a filter could set environment variables.

Courtesy ZDNet

Advertisements

Share your thoughts

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s