What is the CVE-2014-6271 bash vulnerability (Shellshock) and how do I fix it?


Answer #: 1

What is Bash?

Bash is the default interactive shell in Ubuntu. When you are interfacing with the terminal (either through the terminal emulator, over a tty, or ssh), you are generally typing commands that bash will read, and execute. Even if you do not use the terminal at all, you still have Bash.

On Ubuntu, /bin/sh is not bash (it is dash). Only bash is affected by this vulnerability.

How does the exploit affect me?

Bash and the OS keep track of a set of environment variables that describe the current logged-on user, where to look for programs on the hard disk, and other such functions. By crafting an environment variable with a specific structure, an attacker might be able to execute code next time Bash starts.

The attacker can set that environment variable multiple ways:

Remotely connect to a service such as SSH with a specific setup such as git over ssh. As Mitre warns, the use of the sshd ForceCommand option is an...
0 0

Shellshock (CVE-2014-6271)

Bash or Bourne Again Shell is prone to a remote code execution vulnerability in terms of how it processes specially crafted environment variables. Most Linux and Unix based systems are vulnerable since the Bash shell is one of the most common installs on a Linux system and is widely used. A lot of programs like SSH, telnet, CGI scripts allow bash to run in the background allowing the vulnerability to be exploited remotely over the network which makes it more scary. Refer to Wolfgang’s post BASH Shellshock vulnerability – Update5 for more details on the vulnerability.

Proof of Concept

A simple test to check if your Bash is vulnerable is available publicly.

$ env var='() { ignore this;}; echo vulnerable' bash -c /bin/true

Upon running the above command, an affected version of bash will output "vulnerable".

Once the patch has been applied, the same test will return the following result.

bash: warning: var: ignoring...
0 0

- Mint 17 Mate 64-bit

According to NIST, vulnerability CVE-2014-6271 is described: "GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution."

csoonline.com says: "An environmental variable with an arbitrary name can carry a nefarious function which can enable network exploitation. This is fire bad."

I have never knowingly used those features and don't know anything about the environment variables, but my questions are:

1) Is "nefarious" accurate or should they have used "careless" in describing the function "which can enable...

0 0

What is the “bash” vulnerability?

The “bash” vulnerability, actually described as CVE-2014-6271, is an extremely powerful vulnerability due to its high impact and the ease with which it can be exploited. An attacker can simply execute system level commands, with the same privileges as the affected services.

In most of the examples on the Internet right now, attackers are remotely attacking web servers hosting CGI scripts that have been written in bash or pass values to shell scripts.

At the time of writing, the vulnerability has already been used for malicious intentions – infecting vulnerable web servers with malware, and also in hacker attacks. Our researchers are constantly gathering new samples and indications of infections based on this vulnerability; and more information about this malware will be published soon.

The key thing to understand is that the vulnerability is not bound to a specific service, for example Apache or nginx. Rather, the...

0 0

A flaw was found in the way Bash evaluated certain specially crafted environment variables. An attacker could use this flaw to override or bypass environment restrictions to execute shell commands. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue. In this guide we will show how to check for Shellshock Bash Vulnerability and how to fix it in multiple Linux Operating systems such as Debian based Ubuntu, Linux Mint and Red Hat Based CentOS, Fedora distributions.

The GNU Bourne Again shell (Bash) is a shell and command language interpreter compatible with the Bourne shell (sh). Bash is the default shell for Red Hat Enterprise Linux. Red Hat (and rest of the open source community) would like to thank Stephane Chazelas for reporting this issue.

All bash users are advised to upgrade to these updated packages, which contain a back-ported patch to correct this issue.


0 0

Since September 24th , when word of this vulnerability got out, the CVE-2014-6271 bash bug (quickly dubbed Shellshock or Bashdoor) has gone viral over every media outlet.

In alignment with its witty nickname , a serious aftermath is to be expected if this bug gets exploited on large scale . According to ITNews, Akamai Technologies and the United States Department of Defense yesterday reported having been attacked by the first botnet taking advantage of this vulnerability .

This post aims at clarifying in simple terms the nature of the “bash bug” , who’s impacted and how to mitigate its effect , based on the info that is currently available .

So…what is Shellshock ?

Among all the explanations out there, we found Florian Weimer’s one from the original bug description to be , in a nutshell, the most comprehensive:

Bash supports exporting not just shell variables, but also shell functions to other bash instances, via the process environment to...

0 0

I'm using Natty 11.04, which is EOL (and I have updated /etc/apt/sources.list to use old-releases.ubuntu.com), so I have to build from source. I wanted to build a .deb, so at least the package manage is "aware" the bash version is not the default one. I am not 100% succesful - however, the package is registered as "newer" and the bash binary ends up fixed, so here is what I did:

apt-get source bash wget https://gist.githubusercontent.com/drj11/e85ca2d7503f28ebfde8/raw/31bd53ed2e47b220d3c728f5440758e0f76769de/gistfile1.c -O bash_CVE-2014-6271.patch wget https://gist.githubusercontent.com/drj11/239e04c686f0886253fa/raw/046e697da6d4491c3b733b0207811c55ceb9d927/gistfile1.c -O bash_CVE-2014-6271_plus.patch cd bash-4.2/

Now, in the (sub)directory bash-4.2/, there is: a file bash-4.2.tar.xz, which needs to be unpacked to get to the bash source; and a subdirectory called debian.

I made the following changes to avoid dependencies on texlive: in bash-4.2/debian/control:

0 0

Red Hat has been made aware of a vulnerability affecting all versions of the bash package as shipped with Red Hat products. This vulnerability CVE-2014-6271 could allow for arbitrary code execution. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue.

Update: 2014-09-30 18:00 UTC

Two new flaws have been reported that are mitigated by the currently available Bash packages. Please refer to the FAQ for further information.

Update: 2014-09-29 05:00 UTC

Malware is circulating that exploits this vulnerability. For more details, see this article.

Update: 2014-09-26 05:15 UTC

Red Hat has become aware that the patch for CVE-2014-6271 is incomplete. An attacker can provide specially-crafted environment variables containing arbitrary commands that will be executed on vulnerable systems under certain conditions. The new issue has been assigned...

0 0

CVE-2014-6271 is a high impact critical fix. If you are running a Linux system, you should fix this vulnerability.

This CVE-2014-6271 (and CVE-2014-7169) vulnerability is also called as Shellshock.

A flaw was found in the way Bash evaluated certain specially crafted environment variables. An attacker could use this flaw to override or bypass environment restrictions to execute shell commands. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue.

Using bash shell, this vulnerability allows an attacker to execute random shell commands on your environment. The idea behind this is an attacker can bypass the environment variable restriction, which allows him to execute shell commands.

Please note that some services (or application) that are running on Linux servers might allow unauthenticated attackers to specify some environment variables, which will in-turn allow...

0 0
0 0
0 0
0 0

Updated @ 8:10am, September 29: Another remote code execution vulnerability has been found in Bash. It is unrelated to the first Shellshock vulnerability, but it is essentially the same deal: It’s very easy to exploit, and allows attackers to execute arbitrary code on a remote computer. The patched version of Bash which fixed the initial Shellshock vulnerability (CVE-2014-6271) does not protect you against this new vulnerability (CVE-2014-6277 and CVE-2014-6278). The original story, which is still accurate and informative, remains below.

Original story

There’s a new internet-crippling zero-day vulnerability in town called Shellshock. It potentially affects around half of all websites on the internet (around 500 million), and millions or billions more internet-connected devices such as routers, smartphones. Unlike Heartbleed, which was quite hard to exploit properly, Shellshock can be exploited with just a couple of lines of code, giving just about anyone the ability...

0 0
Product Defect Fixed releases availability Cisco ACE Application Control Engine Module for the Cisco Catalyst 6500 CSCur02931 Contact TAC for upgrade options. Cisco Application Control Engine (ACE10 and ACE20) CSCur07312 Contact TAC for upgrade options. Cisco Application Control Engine (ACE30/ ACE 4710) CSCur02195 (A patch is available for vulnerable releases.)
A5(3.1b) (30-Nov-14) Cisco Application and Content Networking System (ACNS) CSCur05564 5.5.37 (5-Dec-14) Cisco DC Health Check CSCur09963 DCAF 4.0 (Available) Cisco GSS 4492R Global Site Selector CSCur02747 4.1(3.0.7) (Available)
3.2(0.1.4) (Available) Cisco NAC Appliance CSCur03364 A patch file is available for vulnerable releases. Cisco Smart Call Home CSCur05551 A patch file is available for vulnerable releases. Cisco Sourcefire Defense Center and Sensor Product
0 0

You don't need to be using bash explicitly for this to be an issue. The real problem is allowing attackers to have a say in the value of environment variables. After the environment is set, it's only a matter of time before some shell gets executed (maybe unknown to you) with an environment it was not prepared for.

Every program (bash, java, tcl, php, ...) has this signature:

int main(int argc, char** argv, char** arge);

Developers are in a habit of checking argc and argv for cleanliness. Most will ignore arge and make no attempt to validate it before spawning subshells (explicitly or implicitly). And in this case bash is not correctly defending itself from bad input. In order to wire an application together, subprocesses get spawned. At the bottom of it, something like this happens:

//We hardcoded the binary, and cleaned the arg, so we assume that //there can be no malicious input - but the current environment is passed //in implicitly. execl("/bin/bash", "bash",...
0 0