The Shellshock FAQ: Here's what you need to know

The situation with the Shellshock bug is so fluid and complicated that even insiders have trouble keeping it all straight. These questions and answers may help you to understand the bug — actually "bugs" — and what you should do about them.

The primary author of these questions and answers is Michael Lin, Security Research Engineer atFireEye, Inc. FireEye provides research and security products to protect enterprise and government networks against threats.

What is Shellshock?

Shellshock is a nickname for a bug in the Bash (Bourne Again SHell) command-line interpreter, also known as a shell. The Bash shell is widely distributed as the default command-line interpreter on many operating systems including most flavors of Linux, many flavors of Unix, some flavors of BSD, and Apple's OSX (since 10.3).

Read this

·      

The Bash shell can also be found on many other systems, from Windows to Android. However it is not installed and/or used by default on these systems.

Since the announcement of the initial Shellshock bug (CVE-2014-6271), related bugs in Bash were found by various researchers. See the full list (so far) below. The most significant of these is still the CVE-2014-6271 bug and references to Shellshock below refer to it, except where otherwise indicated

Who is vulnerable?

Theoretically, all users of Bash are vulnerable. However, only users of Bash that are connected to the Internet are exposed to remote exploitation. Additionally, certain software is necessary to provide a route through which an attacker can reach Bash.

Systems running Internet servers are the most vulnerable and likely to be targeted. Home users who have Bash on a personal computer may also be exposed if they use untrusted networks (i.e. Public Wi-Fi access points).

The average Internet user running Windows, Mac OS, iOS or Android is not vulnerable, at least not by default. But the compromise of Internet servers trusted by those users could facilitate other attacks on clients by the server, and confidential user data on the servers could be exposed to attackers.

Where does the bug occur?

The bug is found in Bash's parsing code. There is an error in the way that Bash parses environment variables during its initialization sequence. Anything that can manipulate the environment variables has the potential to be a vector for this vulnerability.

How does it make you vulnerable?

The Bash bug allows an attacker to perform the same commands as a legitimate user. This gives a successful attacker the ability to do nearly anything that a user can do. An attacker that has access to a remote vector will be able to remotely inject Bash commands on the system without authentication.

Note that the attacker is (at least initially) limited to the privilege level of the user running the Bash instance. However, once an attacker has a foothold in your system, they have multiple options for escalating privileges and potentially gaining root access.

How are people exploiting it?

HTTP Servers
Most attacks on this vulnerability are targeting HTTP web servers. Servers that run the Common Gateway Interface (CGI) or FastCGI have the capability to expose Bash to a HTTP request vector. A maliciously crafted HTTP request can allow an attacker to inject arbitrary commands onto the server and Bash will execute them, if invoked.

Bash can be called directly by the CGI (i.e. A Bash script), or it could be called via a subprocess or system command. If Bash is started at any point within the context of this malicious CGI request, then the vulnerability will be triggered.

For example, CGI could execute a PHP script, which includes a call to system. On systems where Bash is the default shell, this will result in Bash being initialized, triggering the vulnerability.

DHCP Clients
DHCP clients based on the reference implementation from the Internet Systems Consortium (ISC) are also vulnerable. This includes most Linux and Unix systems, but OSX is unaffected. This vector can be exploited when the victim connects to a malicious DHCP server. The vulnerable DHCP client will use variables provided by the DHCP server and save them as environment variables. The DHCP client uses Bash to configure the network interfaces.

This can happen if the user connects to a public Wi-Fi access point or a rogue DHCP server.

Another possibility is that an attacker could use the CGI vector for the attack to compromise the DHCP service on a legitimate server.

SSH
Many SSH systems are set up to restrict the commands that a user can access. The Bash bug can be used to break out of these restrictions. Note that this will require authentication. Therefore, this vector represents a privilege escalation.

Many systems make use of SSH, such as rsync, rlogin, git, subversion, etc. These systems are also affected.

Common Unix Printing System (CUPS)
CUPS is a print server found on many Linux, BSD and Unix systems. CUPS uses user controlled variables to set environment variables when processing filters. This has the potential to be a vector for this vulnerability if Bash is initialized by CUPS during this process. This vector is theoretical at the moment and we have not seen this in the wild yet.

Browser Plug-ins
Third party plug-ins may exist that will set environment variables using user-controlled values. This may create a viable vector, although this has yet to be seen in the wild.

Additional Vectors
Given the widespread availability of Bash, it is possible for additional remote vectors to be discovered in the coming weeks.

How serious is it?

At the time the bug was first publicly disclosed, at least several hundred thousand Internet connected servers were readily vulnerable to exploitation. This is a conservative estimate. It is very likely that many of these servers have since been compromised.

This bug is trivial to exploit. Special tools and custom code is not required. It is also easy to understand, from a conceptual level. Proof-of-concept scripts, demos and kits are already widely available.

The outcome of exploitation is very severe. It typically allows command injection, remotely, without authentication. Once a vector is found, arbitrary code execution is often trivially obtained.

This bug has existed in the Bash code for over two decades. It is possible that various individuals could have discovered this bug on their own and kept it private. It is also possible that this bug has been used in the wild for malicious purposes prior to its public discovery. However it is equally possible that this bug was unknown to the world prior to its public discovery.

The combination of the large number of vulnerable servers, accessibility of exploit tools and the severe outcome of successful exploitation, means that this vulnerability is extremely severe.

What can security teams do to protect themselves?

Patch your systems. Obtain the latest patches from your vendor and patch your Bash to the latest version. Bear in mind that patches may be reissued by the maintainer and new patches are expected for Bash vulnerabilities which remain unpatched.

Check your exposure. Red Hat has an excellent guide on how to determine if your system is unpatched and vulnerable (link).

If you cannot patch Bash, or a patch is not available for your platform, consider switching to another shell.

Update your network and server security products. Make sure your IPS systems are updated with the correct rule sets to detect and prevent exploitation attempts.

Maintain vigilance against rogue servers and access points in your network and on your premises.

How effective can IPS be against these vulnerabilities?

IPS and other types of network based detection are very effective for detecting and preventing Shellshock exploits. The string sequence required to trigger the vulnerability is very distinctive and is fairly easy to parse out. The possibility for false-positives is also relatively low, because the malicious data appears in a specific set of places and the string sequence is rarely used elsewhere.

I'm running Windows. Am I immune?

In general, yes. At this time, there is no evidence that an exploitable Windows vector exists, although it is possible.

While it is possible to install Bash on Windows, it would require a specific set of configuration settings and applications (typically Cygwin or WAMP) to create a situation that has the potential of resulting in a working vector for this vulnerability.

I'm on a Mac. Am I vulnerable?

Strictly speaking, yes, and Apple has released an update to fix the initial vulnerabilities. In practice, you need to have enabled services, i.e. a web server with CGI, which the typical Mac user does not.

I've applied the patch. Am I OK now?

Not entirely. All the major Linux distributions now have patches available for CVE-2014-6271 and CVE-2014-7169, the two original issues. Several other related vulnerabilities in Bash remain unpatched. There are no public reports yet of attacks exploiting these vulnerabilities nor any known proof of concept attacks and they are more difficult to exploit.

Even the patches for the two main vulnerabilities are not yet stable. On Tuesday the Bash maintainerissued a new version of the patch. This version is stricter than the initial patch and was written by Red Hat developers who claimed the initial patch was inadequate. The stricter patch runs a greater, though still small, risk that existing Bash scripts will no longer work. Other vendors, including FreeBSD, NetBSD and VMWare, have gone even further, issuing patches which disabled the vulnerable functionality outright, making incompatibilities more likely.

What are the CVE's for Shellshock?

CVE-2014-6271: This is the original "Shellshock" Bash bug. When most people refer to the Bash bug or "Shellshock", they are most likely talking about this CVE.

CVE-2014-7169: This is the CVE assigned to the incomplete patch for the original bug.

The original patch was found to be incomplete shortly after the vulnerability was publicly disclosed. A variation on the original malicious syntax may allow an attacker to perform unauthorized actions including writing to arbitrary files.

CVE-2014-7186 & CVE-2014-7187: These two CVEs are for bugs discovered in relation to the original Bash bug. These two bugs are triggered by syntax that is very similar to the original Bash bug, but instead of command injection, they allow for out of bounds memory access. There is currently no proof that these bugs have remote vectors and they have not been seen in the wild.

CVE-2014-6277 & CVE-2014-6278: Security researchers discovered two additional bugs. These two bugs are supposed to have the potential for arbitrary command injection, similar to the original Bash bug. However details have not been made public yet, in order to allow appropriate patches to be created.

 Source: zdnet.com