EXADATA--Bash Vulnerabilities, CVE-2014-7169 CVE-2014-6271

These vulnerabilities affects Exadata X3's storage + database servers 

Before giving the action plan to correct the bash vulnerabilities in Exadata, lets have a closer look at these vulnerabilities.

CVE-2014-6271:

The vulnerability is in Bash.. It is also called shellshock.

The vulnerability arises when you put the commands after closing the brace that defines a shell function. 

So, when a new bash is spawned, it interprest the environment variable ( function) but also executes the commands coming afterwards.

To check this, following, command may be used;

export erm='() { echo "function erm" ; }; echo "you are affected"; '

[root@osrvdb01 ~]# bash

If you are affected -> 

The output will be : 

you are affected

If you are safe - >

The output will be :

export erm='() { echo "function erm" ; }; echo "you are affected"; '

[root@erpdev ~]# bash

bash: warning: erm: ignoring function definition attempt

bash: error importing function definition for `erm

In Exadata X3, we have GNU bash version 3.2.25 , and it is affected by this vulnerability.

CVE-2014-7169:

The vulnerability is in Bash. It is also called as shellshock. It seems that, it is in the parser and if you can trigger a proper syntax error, you can execute commands using next bash input line.

If you see your current system date in the output of the following commands, it means you are in danger;

env Exa='() { (a)=>\' sh -c "echo date"; cat echo

sh: Exa: line 1: syntax error near unexpected token `='

sh: Exa: line 1: `'

sh: error importing function definition for `Exa'

Wed Oct  1 15:09:38 EEST 2014

So, what happens with the command env Exa='() { (a)=>\' sh -c "echo date"; cat echo is that;

when bash is executed,  it interprets the function definition and try to declare it.. But it fails because it has a syntax error, so actually parser fails when parsing the command.

Altough the parser fails, it behaves like a buggy program.

 "(a)=" makes the parser to fail, but parser leaves the  ">"(redirection) character to be evaluated and also the character "\ (next line)

The redirection character ">" leads the output of echo date redirected to a file named echo.

Okay, so far we have started to get to know the vulnerabilities.

Lets look at the risk ;

Following table includes the risk compatability of these vulnerabilities.

Oracle Linux Risk Matrix

CVE#	Component	Protocol	Sub- component	Remote Exploit without Auth.?	CVSS VERSION 2.0 RISK (see Risk Matrix Definitions)							Supported Versions Affected
					Base Score	Access Vector	Access Complexity	Authen- tication	Confiden- tiality	Integrity	Avail- ability
CVE-2014-7169 CVE-2014-6271 CVE-2014-7186 CVE-2014-7187 CVE-2014-6277 CVE-2014-6278	OracleLinux	Multiple	Bash	Yes	10.0	Network	Low	None	Complete	Complete	Complete	4, 5, 6, 7

So as you see above, these vulnerabilities seem remotely exploitable without authentication..

The question comes to mind is ; how this bug can be exploited?

Based on my research, the most common effect seems on CGI. That is, if you are using CGI in your web server , then you may be at risk for Remote Code Execution..

A comprehensible POC was delivered by InvisibleThreat, in the following link; 

https://www.invisiblethreat.ca/2014/09/cve-2014-6271/

In the example given by InvisibleThread, we see that ; 

by using curl and modifiying the user_agent , remote codes can be executed through a web server by getting benefit from the bash vulnerability CVE-2014-6271 ..

The vulnerability arises because the environment variables are set by the web server  and send to every CGI program.

curl -A option is used  to specify the :User-Agent string to be send to the Web Server.

We supply the bad command which benefits from the bash vulnerability and execute what we need to execute without any authentication.. 

That is; Web Server through CGI sets this user-agent in the environment, and while setting the environment our bad environment function decleration comes in to play and our code is executed..

By attacking in this way, attacker can remotely execute its code with the permission of the OS user that runs the web server.. So the attacker can delete the whole Documentroot , and crash the website..(HTTP-404)

Well, we have learned the vulnerabilities, and have seen an example in real life..

Lets take a look what we can do to fix this on Exadata X3;

The vulnerability was reported by Oracle on September 26, 2014 with the title "Security Alert for bash vulnerabilities".

Exadata Storage servers are affected and db nodes are also affected.

Actually, "The MOS document Responses to common Exadata security scan findings (Doc ID 1405320.1)" is what we are looking for..

The action plan for correcting the vulnerabilities in Exadata , is as follows;

Note that : This action plan can be used to correct both of the vulnerabilities: CVE-2014-7169 and CVE-2014-6271

• In database nodes, obtain and update updated bash package using the following version, or later:

bash-3.2-33.el5_11.4.x86_64
To install this package on DB nodes, the exadata-sun-computenode-exact RPM must be removed first. If using Exadata DB server image version 11.2.3.3.0 or later, first run this command: rpm -e exadata-sun-computenode-exact
Then, use this command on all releases to install the updated rpm.
rpm -Uvh <new bash rpm>

• To install this package on storage cells (supported as an exception for this CVE only), install using "rpm -Uvh --nodeps <path to bash rpm>"

For solaris, you may obtain fixes via Note 1930090.1 to address this issue.

Note that : ILOM and NM2-36p Infiniband switch patches planned but not yet available.