It allows the attacker to specify arbitrary commands to execute by changing an environment variable in a specific way. Bash is the default command interpreter for Linux and many other Unix versions and is consequently widespread use. But by itself the vulnerability is not that terrible, after all it is a local vulnerability and BASH is a command interpreter, its only reason to exist is to execute commands, so not such a big deal...

Unfortunately this is not quite true as we need to look at how Bash is used. True in its normal form as command interpreter the attack vectors are quite small. However Bash is very often involved in a networked setup to execute commands and that opens up an interesting attack vector. Imagine a webserver that allows you to ping an IP address (my router at home has that function for example), it will most likely just call the "ping" executable with the argument that you supplied, probably checking whether the argument is formatted correctly as an IP address.

RedHat has an extended list of situations that involve Bash in a remote context and you can see it has the potential be a widespread problem, similar to Heartbleed in April. Some of the security researchers involved at the time, namely @ErrataRob have already started their Internet wide scans looking for vulnerable servers:

Apache server using mod_cgi or mod_cgid are affected if CGI scripts are either written in bash, or spawn subshells. Such subshells are implicitly used by system/popen in C, by os.system/os.popen in Python, system/exec in PHP (when run in CGI mode), and open/system in Perl if a shell is used (which depends on the command string)

ForceCommand is used in sshd configs to provide limited command execution capabilities for remote users. This flaw can be used to bypass that and provide arbitrary command execution. Some Git and Subversion deployments use such restricted shells. Regular use of OpenSSH is not affected because users already have shell access.

DHCP clients invoke shell scripts to configure the system, with values taken from a potentially malicious server. This would allow arbitrary commands to be run, typically as root, on the DHCP client machine.

Various daemons and SUID/privileged programs may execute shell scripts with environment variable values set / influenced by the user, which would allow for arbitrary commands to be run.

Any other application which is hooked onto a shell or runs a shell script as using bash as the interpreter. Shell scripts which do not export variables are not vulnerable to this issue, even if they process untrusted content and store it in (unexported) shell variables and open subshells.

To check the Vulnerability

env x='() { :;}; echo vulnerable' bash -c 'echo hello'

If you get an out put like

==

Vulnerable

hello

==

The Bash is said to be Vulnerable

If you get an output like

====

bash: warning: x: ignoring function definition attempt

bash: error importing function definition for `x'

hello

====

The Bash is not Vulnerable.

Fixes,

For redhat ,centos ,debian and ubuntu the patches are already available in the repos

In redhat/Centos

yum update bash

In debian/Ubuntu

apt-get update && apt-get install --only-update bash

Or else if you want to Compile and install the latest bash

apt-get install wget patch gcc make

yum install wget patch gcc make

mkdir src

cd src

wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz

#download all patches

for i in $(seq -f "%03g" 0 25); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done

tar zxvf bash-4.3.tar.gz

cd bash-4.3

#apply all patches

for i in $(seq -f "%03g" 0 25);do patch -p0 < ../bash43-$i; done

#build and install

./configure && make && make install

cd ..

cd ..

rm -r src

Once patches are applied check the vulnerability again and make sure its fine.

More updates are been coming regarding this Will keep you updated.

Workaround: Using mod_security:

The following mod_security rules can be used to reject HTTP requests containing data that may be interpreted by Bash as function definition if set in its environment. They can be used to block attacks against web services, such as attacks against CGI applications outlined above.

These may result in false positives but it's unlikely, and they can log them and keep an eye on it. You may also want to avoid logging as this could result in a significant amount of log files.

Workaround: Using IPTables:

A note on using IPTables string matching:

iptables using -m string --hex-string '|28 29 20 7B|'

Is not a good option because the attacker can easily send one or two characters per packet and avoid this signature easily. However, it may provide an overview of automated attempts at exploiting this vulnerability.

Tuesday, September 23, 2014

The algoritm you define determines how HAproxy balances load across your servers. You can set the algorithm to use with the balance parameter.

Round Robin

Requests are rotated among the servers in the backend.

Servers declared in the backend section also accept a weight parameter which specifies their relative weight. When balancing load, the Round Robin algorithm will respect that weight ratio.

Example:

...

option tcplog

balance roundrobin

maxconn 10000

...

Static Round Robin

Each server is used in turn, according to the defined weight for the server. This algorithm is a static version of the round-robin algoritm, which means that changing the weight ratio for a server on the fly will have no effect. However, you can define as many servers as you like with this algorithm. In addition, when a server comes online, this algoritm ensures that the server is immediately reintroduced into the farm after re-computing the full map. This algoritm also consome slightly less CPU cycles (around -1%).

Example:

...

option tcplog

balance static-rr

maxconn 10000

...

Least Connection

Each server is used in turn, according to the defined weight for the server. This algorithm is a static version of the round-robin algoritm, which means that changing the weight ratio for a server on the fly will have no effect. However, you can define as many servers as you like with this algorithm. In addition, when a server comes online, this algoritm ensures that the server is immediately reintroduced into the farm after re-computing the full map. This algoritm also consome slightly less CPU cycles than the Round Robin algorithm (around -1%).

Example:

...

option tcplog

balance leastconn

maxconn 10000

...

Source

A hash of the source IP is divided by the total weight of the running servers to determine which server will receive the request. This ensures that clients from the same IP address always hit the same server, which is a poor man's session persistence solution.

Example:

...

option tcplog

balance source

maxconn 10000

...

URI

This algorithm hashes either the left part of the URI (before the question mark) or the whole URI (if the whole parameter is present) and divides the hash value by the total weight of the running servers. The result designates which server will receive the request. This ensures that the proxy will always direct the same URI to the same server as long as all servers remain online.

This is used with proxy caches and anti-virus proxies in order to maximize the cache hit rate. This algorithm is static by default, which means that changing a server's weight on the fly will have no effect. However, you can change this using a hash-type parameter.

You can only use this algorithm for a configuration with an HTTP backend.

Exampple:

...

option tcplog

balance uri

maxconn 10000

...

URL Parameter

The URL parameter specified in argument will be looked up in the query string of each HTTP GET request.

You can use this algorithm to check specific parts of the URL, such as values sent through POST requests. For example, you can set this algorithm to direct a request that specifies a user_id with a specific value to the same server using the url_param method. Essentially, this is another way of achieving session persistence in some cases (see the official HAproxy documentation for more information).

Friday, September 19, 2014

Installing Applications along with the heat template. If needed we can mention the network ID, Image ID etc in the file itself instead of asking it from outside.
================================================
heat_template_version: 2013-05-23

on mysql Server
mysql
CREATE DATABASE heat;
GRANT ALL PRIVILEGES ON heat.* TO 'heat'@'localhost' IDENTIFIED BY 'test4heat';
GRANT ALL PRIVILEGES ON heat.* TO 'heat'@'%' IDENTIFIED BY 'test4heat';
GRANT ALL PRIVILEGES ON heat.* TO 'heat'@'192.168.10.30' IDENTIFIED BY 'test4heat';
GRANT ALL PRIVILEGES ON heat.* TO 'heat'@'192.168.10.31' IDENTIFIED BY 'test4heat';
GRANT ALL PRIVILEGES ON heat.* TO 'heat'@'192.168.10.35' IDENTIFIED BY 'test4heat';
GRANT ALL PRIVILEGES ON heat.* TO 'heat'@'192.168.10.32' IDENTIFIED BY 'test4heat';
GRANT ALL PRIVILEGES ON heat.* TO 'heat'@'192.168.10.36' IDENTIFIED BY 'test4heat';
FLUSH PRIVILEGES;
exit
Create the heat service tables

The example uses the IP address of the controller (10.0.0.11) instead of the controller host name since our example architecture does not include a DNS setup. Make sure that the instances can resolve the controller host name if you choose to use it in the URLs.
openstack-config --set /etc/heat/heat.conf DEFAULT heat_metadata_server_url http://192.168.10.30:8000
openstack-config --set /etc/heat/heat.conf DEFAULT heat_waitcondition_server_url http://192.168.10.30:8000/v1/waitcondition

service openstack-heat-api start
service openstack-heat-api-cfn start
service openstack-heat-engine start
chkconfig openstack-heat-api on
chkconfig openstack-heat-api-cfn on
chkconfig openstack-heat-engine on

I use rsync with ssh and authorized key files for auto login to mirror a remote system to the local one.The only change I made was on my .bashrc on the remote end I added in some commands to show file system usage. do a du -f and a tail of the log on login for conveniences.

My assumption here is that when rsync executes the ssh to connect it received 'junk'. Once I removed the extra output from the .bashrc file on the remote end, it worked just fine.SO check your remote end for .profile, .bashrc, .bash_profile etc.... any scripts running that add extra output on login.

CREATE DATABASE cinder;
GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'localhost' IDENTIFIED BY 'cinder4admin';
GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'10.1.15.30' IDENTIFIED BY 'cinder4admin';
GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'%' IDENTIFIED BY 'cinder4admin';
GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'10.1.15.31' IDENTIFIED BY 'cinder4admin';
GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'10.1.15.35' IDENTIFIED BY 'cinder4admin';
GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'10.1.15.36' IDENTIFIED BY 'cinder4admin';
GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'10.1.15.32' IDENTIFIED BY 'cinder4admin';
GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'10.1.15.42' IDENTIFIED BY 'cinder4admin';
exit;

Tuesday, September 2, 2014

Open the command prompt with elevated privileges. To do this click the Start Orb then All Programs, click on Accessories, then right-click on Command Prompt and then select Run as administrator.In the Command Prompt, type

The code example above is almost identical to the HTTP sample, with the main difference being that the $source variable has “ftp” at the beginning instead of “http”. You may also notice that we have used the -Credential parameter since FTP connections generally require a username and password.